Download to read offline
![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.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-44-320.jpg)
![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.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-52-320.jpg)
![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](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-54-320.jpg)
![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-](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-57-320.jpg)
![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](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-59-320.jpg)
![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.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-60-320.jpg)
![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.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-63-320.jpg)
![54 Introduction to Tabu search
6.2 Concepts
6.2.1 Search space
The search space is the set of all possible solutions the local search can visit.
The name ”search space” arises from the following metaphor; if you consider
the variation of a cost function to be a landscape of potential solutions to a
problem where the height of each feature represents its cost.
In general the search space will have at least the size of the feasible space since
it would be unwise to eliminate possible good (or optimal) solutions from the
search. The reason for applying a metaheuristic is when a problem is computa-
tionally hard, i.e. the feasible space is enormous.
Defining the search space can for some problems seem very obvious, but that is
not always so. Sometimes it is not a good idea to restrict the search space to
feasible solutions, several cases have shown that a move to an infeasible solution
can be a very good idea. Today several methods of allowing infeasible solutions
in the search space exist, i.e. ”Constraint Relaxation” or ”Strategic Oscillation”.
[10] pp. 169.
6.2.2 Neighborhood
Assume an element in the search space x, i.e. a solution. Then all the possible
transformations of x leading to another solution in the search space, are defined
as neighbors of x. All the possible single transformations of x together define the
entire neighborhood of x. This leads to the conclusion that the neighborhood
is a subset of the search space.
The Operation research literature states over and over, that choosing a search
space and a neighborhood structure is by far the most critical step in the design
phase of the Tabu search algorithm.
6.2.3 Short term memory
In this section focus will be on short term memory. Candidate list strategies and
the tabu list are examples of short term memory. The name short term memory
is derived from the usage of candidate lists and the tabu list, since both of them](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-66-320.jpg)
![6.2 Concepts 55
only consider the recently achieved knowledge.
6.2.3.1 Candidate list
When determining which neighbor to move along to from an existing solution,
the candidate list holds the neighbors that are to be investigated, meaning that
the candidates of x is a subset of the neighbors of x. Three good motivators for
making use of candidate list:
• The first motivation for building candidate lists is the observation that
both the efficiency and efficacy of a search can be greatly influenced by
isolating good candidate moves.
• The second motivation comes from the need to reduce the computing time
needed for evaluation, i.e. when objective value is expensive to calculate.
• The third motivation comes from the possibility of exploiting the problem
structure, meaning that particular problems lead to special constructions
of intelligent candidate lists1
.
6.2.3.2 Tabu list
The tabu list is a list containing entities from the latest chosen neighbors. There-
fore when considering future moves, the reverse move of the performed one is
deemed tabu.
Tabu tenure is the way of keeping track of the status of move attributes that
compose tabu restrictions and more important, when these restrictions are ap-
plicable. Through history several ways of doing this have been proposed. This
section will explain the most commonly used tabu tenures according to the lit-
erature. The rules of tabu tenures can be divided into two classifications, the
static and the dynamic tenures.
The static rules are defined as ones where the tabu list length remains fixed
throughout the entire search. For example a constant length of between 7 and
20, or a degressive growing function in the number of decision variables like
example
√
n where n is a measure of the problem size. [16, p. 94].
1Context related rules.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-67-320.jpg)
![56 Introduction to Tabu search
The dynamic rules are defined as the ones where the tabu list length vary
throughout the search. For instance a length that randomly or systematically
varies between some static lower and upper bound. More intelligent dynamic
tabu lists can be used to create a more advanced variation, such as long tabu lists
when few improvements can be found. A problem with the dynamic approaches
is that they are very problem dependant.
One way to make the tabu lists more effective is to make use of the a so-called
aspiration criteria.
6.2.3.3 Aspiration criteria
When a move is performed and an intity therefore is declaired tabu, this will
result in more than one solution being tabu. Some of these solutions being
tabu could be of excellent quality, and this is where this aspiration criteria has
its strength. The aspiration criteria is introduced to remove moves from the
tabu list. The most commonly used aspiration criteria, [16] pp. 98, is called
”Aspiration by Objective”. The idea is to remove solutions which have a better
objective value than the currently best known from the tabu list.
Further reading regarding aspiration criteria can be found on pp. 100 in [16]
and on pp. 50 in [11].
6.2.4 Longer Term Memory
Small term memory can be considered as temporary knowledge. Longer term
memory differs from this by encapsulating information from the entire search.
In some Tabu search implementations, the short term memory components are
sufficient to produce high quality solutions. The use of longer term memory does
usually not require very much runtime before the improvements starts becoming
visible. The reason for this success in long term strategies is to be found in the
modified neighborhoods produced by Tabu search; these may contain solutions
not in the original one or combinations of elite solutions leading to even better
solutions. According to [11] pp. 93, the fastest method for some types of routing
and scheduling problems, are based on longer term memory.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-68-320.jpg)
![6.2 Concepts 57
6.2.4.1 Intensification
Intensification is a strategy to modify or change the solution in a way that
seems to be historically good. The idea in intensification resembles the strategy
a human being would make use of. When a part a of solution reappears over
and over again, it might be worth keeping this part of the solution and then
focus on the remaining part of the solution.
Another classical intensification method is the intensification-by-restart method,
which takes the best solution so far, and restarts from there, meaning that the
tabu list is cleared. [11] pp. 96.
6.2.4.2 Diversification
As mentioned earlier in this thesis, one of the main problems with the Tabu
search algorithm is the tendency of being to local. To avoid the algorithm
being to local, diversification is imposed. The observation is that Tabu search
tends to spend most, if not all, of its time in a restricted part of the search
space when making use of only short term memory. The consequence with the
algorithm being to local is that even though it returns good solutions, it might
fail to explore the most interesting parts of the search space. As opposed to
other metaheuristics as for example Genetic algorithms where randomization in
combining population elements provides diversification to the algorithm, Tabu
search has no natural way of diversifying except from the special case where the
tabu list is very long.
Diversification is created to drive the search into new regions of the search space.
One very common diversification strategy is to bring infrequently seen entities
into the solution. This approach forces the algorithm into hopefully new region
of the search space and thereby improve the solution. [11] pp. 98.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-69-320.jpg)
![7.2 Checking legality 67
the number of near nodes can be bounded by a constant, the algorithm has a
time complexity of O(k). The pseudocode of the implemented algorithm can
be seen in appendix B and rigorous proofs for both correctness and the time
complexcity can be found in [20].
The problem concerning removing a job location from a MST is more compli-
cated than the adding problem. However, like the adding problem there exists
a linear algorithm. Unfortunately, this algorithm requires to keep a geometric
structure such as Delaunay triangulation [20]. Further, the time complexity
contains some large constants. Therefore it was in a TRSP context considered
to be faster to build a new MST each time a job was being removed from a
technician plan.
To build MST, Kruskal’s algorithm1
is used. Kruskal’s algorithm first sorts
the edges by cost. Then the edges are added to the MST one at a time in
increasing order. Each edge is only added, if it does not result in a cycle. When
implementing Kruskal, two tricks can be used. The first trick is to use Quick-
Sort2
to sort the edges. Then a lazy approach where only the edges smaller than
the pivot element are sorted recursively, the recursive calls sorting the elements
larger than the pivot element are stored in a stack until needed. This is possible
since Kruskal in each iteration, only needs the edge with the lowest cost. The
second trick is, that the check for cycles is moved into the sorting algorithm so
that edges which will result in a cycle are not sorted but simply discarded. This
could increase the speed, since not all the sorting is done before starting adding
edges to the MST.
The runtime of the Lazy-Kruskal’s algorithm is O(k2
· lg(k)), where k is the
number of vertices, like the standard algorithm since it is not believed that any
of the introduced tricks gives an asymptotic improvement.
The pseudocode of the implemented algorithm can be seen in appendix B.
The proof of correctness for the Lazy-Kruskal algorithm is similar to the proof
of the traditional Kruskal algorithm. I.e after the p’th iteration the p cheapest
edges that do not result in a cycle are chosen. Therefore after the k−1 iteration,
a complete MST is build. It is certain that for each iteration, no cycle is created
since only edges are added to the MST if the two vertices associated with the
edge are not members of the same disjoint set.
1[21] page 569
2[21] page 146](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-79-320.jpg)
![68 Solver foundation
7.2.2 TSP Heuristics
If the transportation time bounds does not provide sufficient information to
answer the question: Whether it is legal to assign job j to technician plan A?
One could determine a good or optimal solution to the TSP and then declare the
assignment legal if the tour is sufficient cheap. Note that if the optimal TSP-
tour is calculated, the question can be answered with certainty, else a heuristic
answer is given.
The largest difference between optimal and near-optimal algorithms to TSP,
is that optimal has an exponential time complexity and guarantee optimality
whereas near-optimal algorithms often have polynomial time complexities, and
if a guarantee is given, this is mostly to weak to be used practical. Ergo, a time
versus quality trade off has to be made.
When TRSP was analyzed in chapter 4, it was concluded that the number
of jobs in each technician plan was small which could argue for an optimal
algorithm. However, this thesis is developing a system which should be as
general as possible, meaning many different clients should be able to use it.
Even though the interviewed clients only have a small number of jobs in each
technician plan, this does not mean that potential future clients does. Note
that the consequence of choosing an optimal algorithm will be an exponential
blow up in computational effort within the engine. Therefore, the choice in
this thesis will be to use a heuristic where the time complexity can be bounded
polynomial. However, the consequense of choosing a heuristic is that the answer
to the question concerning time within the technician plan might end up with
a false negative. This consequence is accepted.
As stated in [15] and [12], the state of the art TSP heuristics are Lin-Kernighan
and a number of other metaheuristics. However, a much simpler heuristic, 2-
opt, is considered a faster alternative, this can be concluded by the results
presented in table 7.1 which is part of the results presented in the downloadable
preliminary version of the chapter in [12], pp. 215-310. The quality of the
heuristics presented in the table, is based on the Held Karp lower bounds.
Since it could be the case that a TSP needs to be solved each time it is checked
whether it is legal to assign a job to a technician plan, computational runtimes
are weighted higher than quality. Therefore 2-opt, based on the results presented
in table 7.1, will be the chosen heuristic to solve instances of TSP in TRSP when
bounds does not provide sufficient information.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-80-320.jpg)
![7.2 Checking legality 69
Algo.N 102
102.5
103
2-Opt 4.5% 0.03 s. 4.8% 0.09 s. 4.9% 0.34 s.
3-Opt 2.5% 0.04 s. 2.5% 0.11 s. 3.1% 0.41 s.
LK 1.5% 0.06 s. 1.7% 0.20 s. 2.0% 0.77 s.
Table 7.1: This table provides results on several heuristics for solving TSP, the
percent excess the percentive value over the Held-Karp lower bound and the
other is the computational time used to find the result.
2-Opt
The 2-Opt algorithm was first proposed by Croes in 1958, although the basics
of the algorithm had already been suggested by Flood in 1956 [12]. The 2-opt
algorithm is a tour improvement algorithm. I.e the input is a Hamiltonian tour
and the output is, if the algorithm can find one, a shorter Hamiltonian tour.
The idea Floods came up with, was to break the tour into two paths, and then
reconnect those paths into the other possible way, see figure 7.6.
Figure 7.6: This figure shows the principle of 2-Opt.
As seen on figure 7.6, the idea is to take two pairs of consecutive nodes from
a tour, here the pairs A & B and C & D. Check and see if the distances
|AB| + |CD| is larger than the distances |AC| + |DB|. If |AB| + |CD| distance
is the largest, then swap A and C which will result in a reversed tour between
those two nodes.
The 2-opt algorithm tries all possible swaps. If an improvement is found, the
swap is made and the algorithm is restarted. The time complexity of 2-Opt
is equal to the number of improvements times the computational effort of one
improvement. One improvement can in worst case require O(k2
), where k is
the number of jobs in the technician plan, if no improvement is found and all
combinations of swaps are tried. The number of improvements is trickier. It
has been proven in [13] that there exist instances and starting tours such that](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-81-320.jpg)
![10.1 Data structures 103
root is the head of the set. This implementation does not provide efficient worst
case bounds on all operations since the Find-Set operation can require linear
work. However, in amortized sense the Find-Set operation is fast since it does
some repair work which is prepaid by the Union operation. Two tricks which
speed up the operations are used. The first trick is union by rank. The idea
is that the smaller tree should be attached to the larger tree when performing
Union. This is done to make the traversal from the leaf to the root in the Find-
Set operation as short as possible. The rank of each node in the tree cannot be
updated in constant time. However, the rank can be bound upwards, and this
upper bound provides sufficient information to allow the amortized analysis to
work. The second trick is path compression. Since the Find-Set operation has
to visit each node on the path from from a start node to the root, then one
could simply maintain the root pointers when visiting the nodes on the way to
the root.
The amortized analysis use a potential function which stores potential in the
data structure according to the sum of rank for the whole forest. This means that
potential is stored in the data structure when performing the Union operation,
which can later be used to run from a node to the root and do path compression.
The pseudocode and a rigorous proof for the time complexity can be found in
[21] page 508. The analysis concludes that n disjoint set operations on a data
structure containing m elements require amortized work equal to O(n · α(m)),
where α(m) is the inverse Ackermann function. This function is constant for all
practical purposes.
10.1.3 Priority Queue
A priority queue is used in the construction algorithm to keep track of the
unassigned jobs. The jobs in the priority queue are prioritized after a ”critical
to assign” measure which describes how many technician plans a specific job
can be assigned to. An important insight from the construction algorithm is,
that each time a job is assigned to a technician plan all jobs in the feasibility
list of that technician plan have to be updated since their critical value may
have changed. This results in a lot of Update Key operations each time a single
Extract Min operation is performed. The priority queue has been implemented
by using a Splay tree since this data structure provides amortized O(lg(n))
running time for these two operations.
A Splay tree is a binary search tree. Whereas most binary search trees, such
as Red-Black trees and AVL trees, guarantee their performance by maintaining
(almost) perfect balance, Splay trees guarantee their performance using amor-](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-115-320.jpg)
![104 Implementation
tization. The idea is that operations are allowed to require much work only if
they are balancing the search tree at the same time, and in this way making
future operations faster.
The balancing in splay trees are done by an operation called Splaying. A Splay
operation consists of a sequence of double rotations. A double rotation involves
three nodes and are performed to do a local balancing between these three nodes.
This balancing results in the total height of the search tree being decreased by
one in enough of these rotations for the amortized analysis to work. A sequence
of rotations where one node is rotated all the way to the root is denoted a Splay.
The potential function used in the amortized analysis is a function that sum
up the size of each possible sub tree. Therefore a balanced tree will have less
potential than an unbalanced one, and since splaying balances the tree a long
search in the splay tree will be paid by the succeeding splay.
A rigorous analysis of the time complexity and pseudocode for all the operations
can be found in [19]. The analysis concludes that all operations on a Splay tree
with n nodes require O(lg(n)) amortized work.
A very nice property of the splay tree node is that recently touched nodes will be
located near the root and will therefore be cached. This is a consequence of the
Splay operation. Recall that the most time consuming part of the construction
algorithm was the backtracking where nodes with low critical value were pushed
back into the priority queue. It can be expected that the Splay tree will provide
high efficiency in the construction algorithm since the Extract-Min operation
will be fast when the element with low critical value is located near the top.
Note that since each operation on a Splay tree with n elements has a time
complexity of O(lg(n)), sorting m elements can by done by first adding each
element and then extracting min m times. This will take O(m · lg(m)) time
which is proven to be optimal for any comparison sorting algorithm1
. The splay
tree is used for sorting in certain cases throughout the implementation.
The Insert operation can be improved by using a lazy strategy. This improve-
ment results in the operation only requiring constant amortized work. This
improvement will however not improve the construction algorithm since a series
of Update Key operations, which contains one Remove and one Insert, is always
followed by a Extract Min which will make the lazyness indifferent.
Another benefit of the Splay tree is that it is quite easy to implement.
1See [21] page 167.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-116-320.jpg)
![10.6 Integration with Dynamics AX 109
10.6 Integration with Dynamics AX
The solver has been integrated in Dynamics AX through the use of a dynamic
linked libary2
. This is possible since Dynamics AX has CLR interoperability
meaning that .NET objects can by instantiated inside Dynamics AX using the
X++ language3
. The X++ code integrating the solver dll with the Dynamics
AX application can be found in appendix F.
The user starts the solver by going through a small wizard. Figure 10.5 shows
the steps necessary to set up the solver. Figure 10.4 shows how a dispatch board
is used to visually show the assignment of service jobs in Dynamics AX. The
dispatch board can therefore be used to show the result of a solver optimization.
Figure 10.4: This dispatch board shows a schedule with three jobs.
2I.e. a .NET managed code .dll file.
3See [5] for more on the workings of Dynamics AX and the X++ language.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-121-320.jpg)
![Appendix A
Guide & API
A.1 Quick guide
This section contains a small guide in using the solver.
The first example shows how to construct and solve a small problem with 1
technician and 1 job.
Schedule schedule = new Schedule();
schedule.AddPeriod(new TimeFrame(60 * 9, 60 * 15));
Technician tech = new Technician("Peter", schedule, new Address("Jagtvej 69",
"København N", "2200", "Denmark"));
Technician[] techs = new Technician[] { tech };
JobDescription job = new JobDescription("Fix elevator", 60 * 2, new TimeFrame(0,
60 * 24), new Address("Strandboulevarden 100", "København Ø", "2100", "Denmark"));
JobDescription[] jobs = new JobDescription[] { job };
TechnicianSkills skills = new TechnicianSkills();
skills.addSkill(tech, job);
HardConstraint[] constraints = new HardConstraint[] { skills };
ProblemDescription problem = new ProblemDescription(techs, jobs, new Assignment[0],
new TimeFrame(0, 60 * 24), constraints);](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-161-320.jpg)
![152 Guide & API
• Address Where the job is going to be performed.
• Timeframe The period of time in which the job is allowed to be performed.
A.2.2.4 ProblemDescription
This class describes a problem. A ProblemDescription is constructed from the
following arguments:
• Technician[] techs An array of the technicians in the problem.
• JobDescription[] greenJobs An array of the jobs, which are going to
be performed by the technicians.
• Assignment[] redJobs An array of jobs which are forced to be performed
by a specific technician at a specific time.
• HardConstraint[] hardConstraints The constraints which can’t be vi-
olated. This could be technician skill levels.1
• Dictionary<Address, Dictionary<Address, int>> distanceMatrix A
matrix with the distance in minutes between each address in the problem
to each of the other addresses. If this argument isn’t specified then the
class calls MapPoint and gets it to calculate the matrix. If there are a
large number of jobs in the problem, then MapPoint might take a while to
calculate this matrix, so it might be a good idea to calculate the matrix
offline.
A.2.2.5 Schedule
A Schedule describes a technicians timeschedule. The schedule is by default
totally empty. The class contains two methods:
public void AddPeriod(TimeFrame period) Adds the timeperiod period
to the schedule.
1See TechnicianSkills section A.2.4.2.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-164-320.jpg)
![B.4 Lazy-Kruskal 161
B.4 Lazy-Kruskal
Input: Graph G - G is an array containing the edges in a graph
Output: MST T
T = ∅;
foreach vertex v in G do
Make-Set(v);
end
push Lazy-QuickSort(G,1, length(G)) into Call-Stack
while size(T) < (# of vertices in G -1 ) do
e = pop Call-Stack;
T = T e;
Union(head(e),tail(e));
end
return T
Algorithm 5: Lazy-Kruskal
Input: Array of edges G, position in G start, position in G end
Output: smallest edge between position start and end in G
while true do
if start < end then
smaller size, larger size = Partition(G,start,end);
Push Lazy-QuickSort(G, end - larger size, end) into Call-Stack;
Push Lazy-QuickSort(G, start, start + smaller size) into
Call-Stack;
end
else if Find-Set(head(start) = Find-Set(tail(start)) then
return G[start];
end
pop Call-Stack;
end
Algorithm 6: Lazy-QuickSort
Input: Array of edges G, position in G start , position in G end
Output: smaller size, larger size
pivot = G[random number between start and end] ;
smaller size =0 ;
larger size = 0 ;
foreach j in G from start to (end - larger size) do
if G[j] < pivot and Find-Set(head(j) = Find-Set(tail(j)) then
swap in G(j, start + smaller size);
smaller size = smaller size + 1;
end
else if G[j] ≥ pivot and Find-Set(head(j) = Find-Set(tail(j)) then
swap in G(j, end - larger size);
larger size = larger size + 1;
j = j-1 ;
end
end
return larger size, smaller size](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-173-320.jpg)
![Appendix E
CP model implementation
Listing E.1: CP model implementation using Optima
1 using System;
2 using System.Collections.Generic;
3 using System.Text;
4 using Microsoft.Planning.Solvers;
5 using System.IO;
6
7 namespace CPSolver
8 {
9 class Program
10 {
11 static void Main(string [] args)
12 {
13 SolveOurProblem ();
14 }
15
16 public static void SolveOurProblem ()
17 {
18 FileInfo mainFile = new FileInfo(" CPSolverTest .txt");
19 using ( StreamWriter sw = new StreamWriter (mainFile.OpenWrite ()))
20 {
21 Random r = new Random (2132);
22
23 int [] nArray = new int[] { 1, 2, 3, 4, 5, 6, 7 };
24 int [] mArray = new int[] { 2, 3, 4, 5 };
25
26 for (int a = 0; a < mArray.Length; a++)
27 {
28 for (int b = 0; b < nArray.Length; b++)
29 {
30 for (int c = 0; c < 5; c++) // Repeats
31 {](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-181-320.jpg)
![170 CP model implementation
32 DateTime startTime = DateTime.Now;
33
34 int n = nArray[b]; // Number of jobs
35 int m = mArray[a]; // Number of TP ’s
36
37 int tp_size = 6*m + (int)((3 * n) / (double)m);
// 200
38
39 int x_max = 4;
40 int y_max = 4;
41
42 double skills = 1;
43 int p_max = 4; // Max prioritet værdi
44 int t_max = 4; // Max skrue
45
46 int d_max = (int)Math.Sqrt(Math.Pow(x_max , 2) +
Math.Pow(y_max , 2)); ;
47
48 int [][] jobPoint = new int[2 * m + n][];
49 int [] homePoint = new int [2] { r.Next(x_max), r.
Next(y_max) };
50
51 {
52 for (int i = 0; i < jobPoint.Length; i++)
53 {
54 jobPoint[i] = new int [2];
55
56 if (i < m || i >= m + n)
57 {
58 jobPoint[i][0] = homePoint [0];
59 jobPoint[i][1] = homePoint [1];
60 }
61 else
62 {
63 jobPoint[i][0] = r.Next(x_max);
64 jobPoint[i][1] = r.Next(y_max);
65 }
66 }
67 }
68
69 int [][] v_ij = new int[m][];
70 {
71 for (int y = 0; y < v_ij.Length; y++)
72 {
73 v_ij[y] = new int[2 * m + n];
74 }
75
76 for (int y = 0; y < v_ij.Length; y++)
77 {
78 for (int t = 0; t < v_ij[y]. Length; t++)
79 {
80 if (t < m || t >= m + n)
81 {
82 v_ij[y][t] = 1;
83 }
84 else
85 {
86 if (skills >= r.NextDouble ())
87 {
88 v_ij[y][t] = 1;
89 }
90 else
91 {
92 v_ij[y][t] = 0;
93 }](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-182-320.jpg)
![171
94 }
95 }
96 }
97 }
98
99 int [][] d_jk = new int[2 * m + n][];
100 {
101 for (int i = 0; i < d_jk.Length; i++)
102 {
103 d_jk[i] = new int[2 * m + n];
104 }
105
106 for (int i = 0; i < d_jk.Length; i++)
107 {
108 for (int j = i; j < d_jk[i]. Length; j++)
109 {
110 int dist = (int)Math.Sqrt(Math.Pow(
jobPoint[i][0] - jobPoint[j][0] ,
2) + Math.Pow(jobPoint[i][1] -
jobPoint[j][1] , 2));
111 d_jk[i][j] = dist;
112 d_jk[j][i] = dist;
113 }
114 }
115 }
116
117
118 int [][] p_ji = new int[m][];
119
120 for (int t = 0; t < p_ji.Length; t++)
121 {
122 p_ji[t] = new int[2 * m + n];
123
124 for (int y = 0; y < p_ji[t]. Length; y++)
125 {
126 if (m <= y && y < m + n)
127 {
128 p_ji[t][y] = 1 + r.Next(p_max); // 1
or 2
129 }
130 }
131 }
132
133 int [] t_j = new int[2 * m + n];
134
135 for (int t = 0; t < t_j.Length; t++)
136 {
137 if (m <= t && t < m + n)
138 {
139 t_j[t] = 1 + r.Next(t_max); // 0 or 1
140 }
141 }
142
143 FiniteSolver S = new IntegerSolver (null , null);
144
145 using (S) // This disposes S after use
146 {
147 ValueSet small_j = S. CreateInterval (1, m);
148 ValueSet large_j = S. CreateInterval (m + n +
1, 2 * m + n);
149 ValueSet middlelarge_j = S. CreateInterval (m +
1, 2 * m + n);
150
151 ValueSet i = S. CreateInterval (1, m);](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-183-320.jpg)
![172 CP model implementation
152 ValueSet j = S. CreateInterval (1, 2 * m + n);
// j is the jobs plus start and end for
each tp
153 ValueSet time = S. CreateInterval (0, tp_size);
// The time to use.
154
155 // Creating the 3 variables
156 Term [] R = S. CreateVariableVector (j, "R_", 2
* m + n);
157 Term [] Q = S. CreateVariableVector (time , "Q_",
2 * m + n);
158 Term [] Tau = S. CreateVariableVector (i, "Tau_"
, 2 * m + n);
159
160 // Creating the 2 objective variables
161 Term [] goal1 = S. CreateVariableVector (S.
CreateInterval (-d_max , 0), "goal1_", 2 *
m + n);
162 Term [] goal2 = S. CreateVariableVector (S.
CreateInterval (0, p_max), "goal2_", 2 *
m + n);
163
164
165 // Creating the constraints
166 // 1
167 S. AddConstraints (S.Unequal(R));
168
169
170 // 2
171 foreach (int t in small_j.Forward ())
172 {
173 S. AddConstraints (S.Equal (0, Q[t - 1]));
174 }
175
176 // 3
177 foreach (int t in large_j.Forward ())
178 {
179 S. AddConstraints (S.Equal(tp_size , Q[t -
1]));
180 }
181
182 // 4
183 foreach (int t in j.Forward ())
184 {
185 foreach (int k in middlelarge_j .Forward ()
)
186 {
187 S. AddConstraints (S.Implies(S.Equal(k,
R[t - 1]), S. GreaterEqual (Q[k -
1], Q[t - 1] + d_jk[t - 1][k -
1] + t_j[k - 1])));
188 }
189 }
190
191 // 5
192 foreach (int t in j.Forward ())
193 {
194 foreach (int y in i.Forward ())
195 {
196 if (v_ij[y - 1][t - 1] == 0)
197 {
198 S. AddConstraints (S.Unequal(y, Tau
[t - 1]));
199 }
200 }](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-184-320.jpg)
![173
201 }
202
203 // 6
204 foreach (int t in small_j.Forward ())
205 {
206 S. AddConstraints (S.Equal(t, Tau[t - 1]));
207 }
208
209 // 7
210 foreach (int t in large_j.Forward ())
211 {
212 S. AddConstraints (S.Equal(t - (m + n), Tau
[t - 1]));
213 }
214
215 // 8
216 foreach (int t in large_j.Forward ())
217 {
218 S. AddConstraints (S.Equal(t - (m + n), R[t
- 1]));
219 }
220
221 // 9
222 foreach (int t in j.Forward ())
223 {
224 foreach (int k in j.Forward ())
225 {
226 S. AddConstraints (S.Implies(S.Equal(k,
R[t - 1]), S.Equal(Tau[k - 1],
Tau[t - 1])));
227 }
228 }
229
230 // The two objective constraints
231
232
233 foreach (int t in j.Forward ())
234 {
235 foreach (int k in j.Forward ())
236 {
237 S. AddConstraints (S.Implies(S.Equal(k,
R[t - 1]), S.Equal(-d_jk[t -
1][k - 1], goal1[t - 1]))); //
the objective is drive away from
238 }
239 }
240
241 foreach (int t in j.Forward ())
242 {
243 foreach (int y in i.Forward ())
244 {
245
246 S. AddConstraints (S.Implies(S.Equal(y,
Tau[t - 1]), S.Equal(p_ji[y -
1][t - 1], goal2[t - 1])));
247 }
248 }
249
250
251 Term [] goals = new Term[goal1.Length + goal2.
Length ];
252 goal1.CopyTo(goals , 0);
253 goal2.CopyTo(goals , goal1.Length);
254
255 // Creating the objective](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-185-320.jpg)
![174 CP model implementation
256 S. TryAddMinimizationGoals (S.Neg(S.Sum(goals))
);
257
258 Dictionary <Term , int > bestSoln = null;
259 foreach (Dictionary <Term , int > soln in S.
EnumerateSolutions ())
260 {
261 bestSoln = soln;
262 }
263
264 if (bestSoln == null)
265 {
266 Console.WriteLine("No solution found");
267 }
268 /* else
269 {
270 PrintSol (R, Q, Tau , goal1 , goal2 ,
bestSoln );
271 }*/
272
273 // calculate obj value
274 int obj = 0;
275 int obj1 = 0;
276 int obj2 = 0;
277
278
279 for (int t = 0; t < 2 * m + n; t++)
280 {
281 obj1 += bestSoln[goal1[t]];
282 obj2 += bestSoln[goal2[t]];
283 }
284 obj = obj1 + obj2;
285
286
287 /* Console . WriteLine (" Obj1 :" + obj1);
288 Console . WriteLine (" Obj2 :" + obj2);
289 Console . WriteLine (" Obj :" + obj);
290
291 Console . WriteLine (" Done ");*/
292 }
293
294 TimeSpan timeUsed = DateTime.Now - startTime;
295
296 Console.WriteLine("n: " + n + " m: " + m + " time
: " + timeUsed. TotalSeconds );
297
298 sw.WriteLine(n + ";" + m + ";" + timeUsed.
TotalMilliseconds );
299 sw.Flush ();
300 }
301 }
302 }
303 }
304 }
305
306 private static void PrintSol(Term [] R, Term [] Q, Term [] Tau , Term []
goal1 , Term [] goal2 , Dictionary <Term , int > soln)
307 {
308 Console.WriteLine("TAU:");
309 for (int tau = 0; tau < Tau.Length; tau ++)
310 {
311 Console.WriteLine(tau +1 + ": " + soln[Tau[tau ]]);
312 }
313
314 Console.WriteLine("R:");](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-186-320.jpg)
![175
315 for (int h = 0; h < R.Length; h++)
316 {
317 Console.WriteLine(h+1 + ": " + soln[R[h]]);
318 }
319
320 Console.WriteLine("Q:");
321 for (int h = 0; h < Q.Length; h++)
322 {
323 Console.WriteLine(h + 1 + ": " + soln[Q[h]]);
324 }
325
326 Console.WriteLine("Cost1:");
327 for (int h = 0; h < goal1.Length; h++)
328 {
329 Console.WriteLine(h + 1 + ": " + soln[goal1[h]]);
330 }
331
332 Console.WriteLine("Cost2:");
333 for (int h = 0; h < goal2.Length; h++)
334 {
335 Console.WriteLine(h + 1 + ": " + soln[goal2[h]]);
336 }
337 }
338 }
339 }](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-187-320.jpg)
![Appendix F
Dynamics AX integration
Listing F.1: X++ class ServiceOptimize
1 public class ServiceOptimize
2 {
3 JobScheduling .Struct.TimeFrame wholeperiod;
4 utcdatetime starttime;
5
6 public void new( utcdatetime _starttime , utcdatetime _endtime )
7 {
8 starttime = _starttime;
9 wholeperiod = new JobScheduling .Struct.TimeFrame (0, this.
convertTime(_endtime));
10 }
11
12 JobScheduling .Struct. SolutionDescription optimize( JobScheduling .
SoftConstraints .Goal goal , JobScheduling .Struct.
ProblemDescription probDesc , int timeInSec)
13 {
14 JobScheduling .Struct. SolutionDescription solution;
15 JobScheduling .Solver solver = new JobScheduling .Solver ();
16 JobScheduling . SolverSettings settings = new JobScheduling .
SolverSettings (new System.TimeSpan (0, 0, timeInSec));
17
18 solution = solver. GenerateSolution (goal , probDesc , settings);
19 return solution;
20 }
21
22 void updateDatabase ( JobScheduling .Struct. SolutionDescription solDesc)
23 {
24 int length;
25 JobScheduling .Struct.Assignment [] assigns;
26 int i;
27 JobScheduling .Struct.Assignment assignment;](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-189-320.jpg)
![178 Dynamics AX integration
28 JobScheduling .Struct. JobDescription job;
29 JobScheduling .Struct.Technician tech;
30 int time;
31 str jobDesc;
32 boolean b;
33 str techName;
34 utcdatetime timeFrom;
35 utcdatetime timeTo;
36 int duration;
37
38 smmActivities activities;
39 smmActivityParentLinkTable linkTable;
40
41 ttsbegin;
42 while select forupdate activities join linkTable
43 where activities. ActivityNumber == linkTable.
ActivityNumber &&
44 linkTable.RefTableId == tablenum( SMAServiceOrderLine )
45 {
46 assigns = solDesc. get_AssignmentArray ();
47 length = assigns.get_Length ();
48
49 b = false;
50 for (i = 0; i < length; i++)
51 {
52 assignment = assigns.GetValue(i);
53 job = assignment.get_Job ();
54 jobDesc = job. get_Description ();
55 if (jobDesc == activities. ActivityNumber )
56 {
57 tech = assignment. get_Technician ();
58 time = assignment.get_Time ();
59 techName = tech.get_Name ();
60 b = true;
61 break;
62 }
63 }
64
65 if (!b)
66 {
67 // Do nothing
68 }
69 else
70 {
71 duration = job. get_Duration ();
72 timeFrom = DateTimeUtil :: addMinutes(starttime
, time);
73 timeTo = DateTimeUtil :: addMinutes(starttime ,
duration + time);
74
75 activities. ResponsibleEmployee = techName;
76 activities. StartDateTime = timeFrom;
77 activities.EndDateTime = timeTo;
78 activities.update ();
79 }
80 }
81 ttscommit;
82 }
83
84 JobScheduling .Struct. ProblemDescription createProblemDescription ()
85 {
86 JobScheduling .Struct.Technician [] techs;
87 JobScheduling .Struct. JobDescription [] greenJobs;
88 JobScheduling .Struct.Assignment [] redJobs;](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-190-320.jpg)
![179
89 JobScheduling . HardConstraints . HardConstraint []
hardConstraints ;
90 JobScheduling .Struct.TimeFrame period;
91 JobScheduling .Struct. ProblemDescription probDesc;
92 JobScheduling .Struct. AddressMatrix matrix;
93 System.IO.FileInfo addrFile;
94 int i;
95 int length;
96 str name;
97 JobScheduling .Struct. JobDescription jobDesc;
98 JobScheduling .Struct.Technician technician;
99 ;
100
101 addrFile = new System.IO.FileInfo("C: addrMatrix.txt");
102 /*
103 * Getting the data from the database .
104 */
105 techs = this. findTechnicians ();
106 this. findCalendars (techs);
107 greenJobs = this.findJobs ();
108 redJobs = new JobScheduling .Struct.Assignment [0](); // No red
jobs.
109 hardConstraints = new JobScheduling . HardConstraints .
HardConstraint [0](); // No extra hard constraints .
110
111 print "Loading the address matrix";
112 /*
113 * Creating the address matrix .
114 */
115 matrix = JobScheduling . AddressMatrixLoader :: Load(addrFile);
116 matrix = new JobScheduling .Struct. AddressMatrix (techs ,
greenJobs , redJobs , matrix);
117 JobScheduling . AddressMatrixLoader :: Save(addrFile , matrix);
118
119 print "Finished loading the address matrix";
120 /*
121 * Finally creating the problem description ...
122 */
123 probDesc = new JobScheduling .Struct. ProblemDescription (techs ,
greenJobs , redJobs , wholeperiod , hardConstraints ,
matrix);
124
125 return probDesc;
126 }
127
128 JobScheduling .Struct.Technician [] findTechnicians ()
129 {
130 Array techs = new Array(Types :: Class);
131 JobScheduling .Struct.Technician [] toBeReturned ;
132 JobScheduling .Struct.Technician tech;
133 JobScheduling .Struct.Address techAddress ;
134
135 int i = 1;
136 int returnLength ;
137
138 /*
139 * Tables
140 */
141 EmplTable emplTable;
142 DirPartyAddressRelationship
dirPartyAddressRelationship ;
143 DirPartyAddressRelationshipMapping
dirPartyAddressRelationshipMapping ;
144 Address address;
145 ;](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-191-320.jpg)
![180 Dynamics AX integration
146
147 while select emplTable join DirPartyAddressRelationship join
DirPartyAddressRelationshipMapping join Address
148 where emplTable. DispatchTeamId != ’’ &&
149 DirPartyAddressRelationshipMapping .
RefCompanyId == Address.dataAreaId
&&
150 DirPartyAddressRelationshipMapping .
AddressRecId == Address.RecId &&
151 DirPartyAddressRelationshipMapping .
PartyAddressRelationshipRecId ==
DirPartyAddressRelationship .RecId &&
152 EmplTable.PartyId
==
DirPartyAddressRelationship .PartyId
153 {
154 // info( strfmt ("%1 , %2", emplTable .EmplId , Address .
Address ));
155
156 techAddress = new JobScheduling .Struct.Address(
Address.Street , Address.City , Address.ZipCode ,
Address. CountryRegionId );
157 tech = new JobScheduling .Struct.Technician(emplTable.
EmplId , new JobScheduling .Struct.Schedule (),
techAddress);
158
159 techs.value(i, tech);
160
161 i++;
162 }
163
164 print "#techs found:";
165 print i-1;
166
167 toBeReturned = new JobScheduling .Struct.Technician[i -1]();
168 returnLength = toBeReturned .get_Length ();
169
170 for (i = 0; i < returnLength ; i++)
171 {
172 toBeReturned .SetValue(techs.value(i+1), i);
173 }
174
175 return toBeReturned ;
176 }
177
178 JobScheduling .Struct. JobDescription [] findJobs ()
179 {
180 int duration;
181 JobScheduling .Struct.Address address;
182 JobScheduling .Struct. JobDescription job;
183
184 JobScheduling .Struct. JobDescription [] toBeReturned ;
185 Array jobs = new Array(Types :: Class);
186 int i = 1;
187 int returnLength ;
188
189 /*
190 * Tables
191 */
192 EmplTable emplTable;
193 smmActivities activities;
194 smmActivityParentLinkTable linkTable;
195 SMAServiceOrderLine serviceLine;
196 SMAServiceOrderTable serviceOrder ;
197 ;](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-192-320.jpg)
![181
198
199 while select emplTable join activities join linkTable join
serviceLine join serviceOrder
200 where emplTable. DispatchTeamId != ’’ && empltable.
CalendarId != ’’ &&
201 activities. ResponsibleEmployee == emplTable
.EmplId &&
202 activities. ActivityNumber == linkTable.
ActivityNumber &&
203 linkTable.RefTableId == tablenum(
SMAServiceOrderLine ) &&
204 serviceLine.ActivityId == activities.
ActivityNumber &&
205 serviceLine. ServiceOrderId == serviceOrder .
ServiceOrderId
206
207 {
208 // info( strfmt ("%1 %2 %3 %4", activities .
ActivityNumber , activities . StartDateTime ,
activities . EndDateTime , serviceOrder .
ServiceAddress ));
209
210 duration = this.convertTime(activities.EndDateTime) -
this. convertTime (activities. StartDateTime );
211 address = new JobScheduling .Struct.Address(
serviceOrder .ServiceAddressStreet , serviceOrder .
ServiceAddressCity , serviceOrder .
ServiceAddressZipCode , serviceOrder .
ServiceAddressCountryRegion );
212 job = new JobScheduling .Struct. JobDescription (
activities.ActivityNumber , duration , wholeperiod
, address);
213
214 jobs.value(i, job);
215 i++;
216 }
217
218 print "#jobs found:";
219 print i-1;
220
221 toBeReturned = new JobScheduling .Struct. JobDescription [i -1]()
;
222 returnLength = toBeReturned .get_Length ();
223 for (i = 0; i < returnLength ; i++)
224 {
225 toBeReturned .SetValue(jobs.value(i+1) , i);
226 }
227
228 return toBeReturned ;
229 }
230
231 void findCalendars ( JobScheduling .Struct.Technician [] techs)
232 {
233 JobScheduling .Struct.Schedule s;
234 JobScheduling .Struct.Technician t;
235
236 utcdatetime timeFrom;
237 utcdatetime timeTo;
238 int fromInt;
239 int toInt;
240
241 int length;
242 int indx;
243 str techName;
244 JobScheduling .Struct.TimeFrame techFrame;](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-193-320.jpg)
![183
296 s.AddPeriod(techFrame
);
297 break;
298 }
299 }
300 }
301 }
302 }
303 }
304
305 int convertTime( utcdatetime dtime)
306 {
307 int64 diff = DateTimeUtil :: getDifference (dtime , starttime);
308
309 int diffInMinutes = diff / 60;
310
311 return diffInMinutes ;
312 }
313 }
Listing F.2: Method called by the the wizard when pressing finish
1 public void closeOk ()
2 {
3 JobScheduling .Struct. SolutionDescription solDesc;
4 JobScheduling .Struct. ProblemDescription probDesc;
5 JobScheduling . SoftConstraints .Goal goal;
6 int i;
7 int length;
8 JobScheduling .Struct.Assignment [] assArray;
9 JobScheduling .Struct.Assignment assign;
10 JobScheduling .Struct. JobDescription jobDesc;
11 ServiceOptimize serviceOptimizer ;
12 utcdatetime fromTime;
13 utcdatetime toTime;
14 ;
15
16 super ();
17
18 // utcdatetime format : 2008 -01 -29 T13 :38:47
19 fromTime = fromDateTime . dateTimeValue ();
20 toTime = toDateTime. dateTimeValue ();
21
22 serviceOptimizer = new ServiceOptimize (fromTime , toTime);
23
24 print "Starting the creation of the problem description ";
25 probDesc = serviceOptimizer . createProblemDescription ();
26 print "The creation of the problem description ended";
27
28 goal = new JobScheduling . SoftConstraints .Goal ();
29 goal. AddConstraint (new JobScheduling . SoftConstraints . DistanceTravelled (
probDesc), travelField .realValue ());
30 goal. AddConstraint (new JobScheduling . SoftConstraints .Robustness(probDesc ,
120) , robustField.realValue ());
31 print "Starting the optimization ";
32 solDesc = serviceOptimizer .optimize(goal , probDesc , optiTime.value ());
33 print " Optimization ended";
34
35 info(solDesc. GetLongString ());
36
37 print "Updating the database";
38 serviceOptimizer . updateDatabase (solDesc);
39 }](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-195-320.jpg)
![Bibliography
[1] Combinatorics, Algorithms, Probabilistic and Experimental Methodologies,
chapter The Tight Bound of First Fit Decreasing Bin-Packing Algorithm
Is FFD(I)≤11/9·OPT(I)+6/9. Springer Berlin / Heidelberg, 2007.
[2] Le Pape Claude Nuijten Wim Baptiste, Philippe. Constraint-Based
Scheduling Applying Constraint Programming to Scheduling Problems.
Kluwer Academic Publishers, London, 2001.
[3] Filippo Focacci, Andrea Lodi, and Michela Milano. A hybrid exact algo-
rithm for the tsptw. INFORMS J. on Computing, 14(4):403–417, 2002.
http://dx.doi.org/10.1287/ijoc.14.4.403.2827.
[4] Robert Ghanea-Hercock. Applied Evolutionary Algorithms in Java. Black-
well Scientific Publications, New York, New York, 2003.
[5] Olsen et al Greef, Pontoppidan. Inside Microsoft Dynamics AX 4.0. Mi-
crosoft Press, Redmond, Washington, 2006.
[6] John E. Hopcroft, Rajeev Motwani, Rotwani, and Jeffrey D. Ullman. In-
troduction to Automata Theory, Languages and Computability. Addison-
Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000.
[7] M. R. Garey & D. S. Johnson. COMPUTERS AND INTRACTABILITY
- A Guide to the Theory of NP-Completeness. Murray Hill, San Francisco,
California, 1979.
[8] R. A. Johnson. Miller & Freund´s Probability and Statistics for Engineers.
Prentice-Hall, London, 2000.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-197-320.jpg)
![186 BIBLIOGRAPHY
[9] P. J. Stuckey K. Marriott. Programming with Constraints - An Introduction.
The MIT Press, Cambridge, Massachusetts, 2001.
[10] E. K. Burke & G. Kendall. SEARCH METHODOLOGIES - Introductory
Tutorials in Optimization and Decision Support Techniques. Springer, New
York, New York, 2005.
[11] F. Glover & M. Laguna. TABU SEARCH. Kluwer Academic Publishers,
Norwell, Massachusetts, 1997.
[12] E. H. L. Aarts & J. K. Lenstra. Local Search in Combinatorial Optimization.
Princeton University Press, London, 1997.
[13] G. Lueker. manuscript. Princeton University, 1976.
[14] Irvin J. Lustig and Jean-Fran¸cois Puget. Program does not equal program:
Constraint programming and its relationship to mathematical program-
ming. Interfaces, 31(6):29–53, 2001. http://dx.doi.org/10.1287/inte.
31.7.29.9647.
[15] C. Nilsson. Heuristics for the traveling salesman problem. http://www.
ida.liu.se/~TDDB19/reports_2003/htsp.pdf.
[16] C. R. Reeves. Modern Heuristic Techniques for Combinatorial Problems.
Blackwell Scientific Publications, London, 1993.
[17] MAURICIO G.C. RESENDE. Greedy randomized adaptive search pro-
cedures (grasp). AT&T Labs Research Technical Report, 2001. http:
//www.research.att.com/~mgcr/doc/sgrasp.pdf.
[18] Stephan Scheuerer. A tabu search heuristic for the truck and trailer routing
problem. Comput. Oper. Res., 2006. http://dx.doi.org/10.1016/j.cor.
2004.08.002.
[19] Robert E. Sleator, Daniel D. & Tarjan. Self-adjusting binary search trees.
Journal of the Association for Computing Machinery, 1985. http://www.
cs.cmu.edu/~sleator/papers/self-adjusting.pdf.
[20] Mike Soss. Online construction of a minimal spanning tree (mst). http:
//cgm.cs.mcgill.ca/~soss/geometry/online_mst.html, 1997.
[21] R. L. Rivest & C. Stein T. H. Cormen, C. E. Leisersoon. Introduction to
Algorithms. The MIT Press, Cambridge, Massachusetts, 2001.
[22] J.P. Rasson V. Granville, K. Krivanek. Simulated annealing: A proff of
convergence. PATTERN ANALYSIS AND MACHINE INTELLIGENCE,
1994, (vol. 16, No. 6) pp. 652-656. http://doi.ieeecomputersociety.
org/10.1109/34.295910.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-198-320.jpg)
![BIBLIOGRAPHY 187
[23] David H. Wolpert and William G. Macready. No free lunch theorems
for search. Technical Report SFI-TR-95-02-010, Santa Fe, NM, 1995.
citeseer.ist.psu.edu/wolpert95no.html.](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-199-320.jpg)
![BIBLIOGRAPHY 189
[11] [10] [5] [7] [21] [6] [12] [16] [4] [8] [2] [9] [19] [15] [17] [18] [22] [14] [13] [3]
[23] [1] [20]](https://image.slidesharecdn.com/503dded7-6a67-40e0-a1a6-1f1df852e418-160708125022/85/ep08_11-201-320.jpg)
ep08_11
- 1. Technician Routing andScheduling Christian Uldall Pedersen, Erik Schmidt Taarnhøj & Søren V¨orts Supervisor: Thomas K. Stidsen Kongens Lyngby 2008
- 2. Technical University ofDenmark 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 wewould 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 introducesand 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.
- 6.
- 7. Resum´e Nærværende afhandling introducererog 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.
- 8.
- 9. Contents 1 Introduction 1 1.1Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Case study 5 2.1 Endress + Hauser . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Wifac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 KONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 TDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Modeling the problem 17 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4 Complexity analysis of TRSP 27
- 10. viii CONTENTS 4.1 Mixedinteger programming . . . . . . . . . . . . . . . . . . . . . 27 4.2 Constraint programming . . . . . . . . . . . . . . . . . . . . . . . 32 4.3 NP completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5 Metaheuristic concepts 45 5.1 Hill climbing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2 Simulated annealing . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.3 Genetic algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4 Tabu search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.5 Semi-greedy construction heuristics . . . . . . . . . . . . . . . . . 50 5.6 Choosing a metaheuristic for TRSP . . . . . . . . . . . . . . . . 51 6 Introduction to Tabu search 53 6.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7 Solver foundation 59 7.1 Technician plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.2 Checking legality . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.3 The bilities data structure . . . . . . . . . . . . . . . . . . . . . . 71 7.4 Delta evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 8 Solver overview 81 8.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
- 11. CONTENTS ix 8.2 Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.3 Diversification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.4 Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 8.5 Solver flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 9 Practical extensions 95 9.1 Large jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 9.2 Infeasible problems . . . . . . . . . . . . . . . . . . . . . . . . . . 97 9.3 Changes to the problem definition . . . . . . . . . . . . . . . . . 98 9.4 Red jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 10 Implementation 101 10.1 Data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 10.2 Extendability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 10.3 Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 10.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 10.5 Solver usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 10.6 Integration with Dynamics AX . . . . . . . . . . . . . . . . . . . 109 11 Solver tuning & practical testing 111 11.1 Test machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 11.2 Solver tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 11.3 Practical test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
- 12. x CONTENTS 12 Discussion139 12.1 Practical overview . . . . . . . . . . . . . . . . . . . . . . . . . . 139 12.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 13 Conclusion 147 A Guide & API 149 A.1 Quick guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 A.2 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 B Pseudocode 157 B.1 Tabu search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 B.2 2-opt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 B.3 AddToMST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 B.4 Lazy-Kruskal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 C Profiling 163 D GAMS model 165 E CP model implementation 169 F Dynamics AX integration 177
- 13. Chapter 1 Introduction Dynamics AXis 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 Problemdefinition 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 definition3 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.
- 16.
- 17. Chapter 2 Case study Asexplained 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.1Endress + 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 tohandle 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 robustnessWifac 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 Apart 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 servicetechnician 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 outTDC 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 hasat 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+HWifac 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+HWifac 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.
- 28.
- 29. Chapter 3 Modeling theproblem 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 theproblem 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 atechnician 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 theproblem • 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 theproblem 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 handlethe 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 theproblem 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 theproblem 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 analysisof 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 analysisof 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 integerprogramming 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 analysisof 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 integerprogramming 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 analysisof 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 programming33 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 analysisof 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 programming35 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 analysisof 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 programming37 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 analysisof 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 completeness39 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 analysisof 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 completeness41 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 analysisof 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 completeness43 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.
- 56. 44 Complexity analysisof TRSP
- 57. Chapter 5 Metaheuristic concepts Metaheuristicsare 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 anteeeither 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 annealing47 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 ofavoiding 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 search49 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.1Pros & 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 ametaheuristic 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 Tabusearch 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 toTabu 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.
- 66. 54 Introduction toTabu search 6.2 Concepts 6.2.1 Search space The search space is the set of all possible solutions the local search can visit. The name ”search space” arises from the following metaphor; if you consider the variation of a cost function to be a landscape of potential solutions to a problem where the height of each feature represents its cost. In general the search space will have at least the size of the feasible space since it would be unwise to eliminate possible good (or optimal) solutions from the search. The reason for applying a metaheuristic is when a problem is computa- tionally hard, i.e. the feasible space is enormous. Defining the search space can for some problems seem very obvious, but that is not always so. Sometimes it is not a good idea to restrict the search space to feasible solutions, several cases have shown that a move to an infeasible solution can be a very good idea. Today several methods of allowing infeasible solutions in the search space exist, i.e. ”Constraint Relaxation” or ”Strategic Oscillation”. [10] pp. 169. 6.2.2 Neighborhood Assume an element in the search space x, i.e. a solution. Then all the possible transformations of x leading to another solution in the search space, are defined as neighbors of x. All the possible single transformations of x together define the entire neighborhood of x. This leads to the conclusion that the neighborhood is a subset of the search space. The Operation research literature states over and over, that choosing a search space and a neighborhood structure is by far the most critical step in the design phase of the Tabu search algorithm. 6.2.3 Short term memory In this section focus will be on short term memory. Candidate list strategies and the tabu list are examples of short term memory. The name short term memory is derived from the usage of candidate lists and the tabu list, since both of them
- 67. 6.2 Concepts 55 onlyconsider the recently achieved knowledge. 6.2.3.1 Candidate list When determining which neighbor to move along to from an existing solution, the candidate list holds the neighbors that are to be investigated, meaning that the candidates of x is a subset of the neighbors of x. Three good motivators for making use of candidate list: • The first motivation for building candidate lists is the observation that both the efficiency and efficacy of a search can be greatly influenced by isolating good candidate moves. • The second motivation comes from the need to reduce the computing time needed for evaluation, i.e. when objective value is expensive to calculate. • The third motivation comes from the possibility of exploiting the problem structure, meaning that particular problems lead to special constructions of intelligent candidate lists1 . 6.2.3.2 Tabu list The tabu list is a list containing entities from the latest chosen neighbors. There- fore when considering future moves, the reverse move of the performed one is deemed tabu. Tabu tenure is the way of keeping track of the status of move attributes that compose tabu restrictions and more important, when these restrictions are ap- plicable. Through history several ways of doing this have been proposed. This section will explain the most commonly used tabu tenures according to the lit- erature. The rules of tabu tenures can be divided into two classifications, the static and the dynamic tenures. The static rules are defined as ones where the tabu list length remains fixed throughout the entire search. For example a constant length of between 7 and 20, or a degressive growing function in the number of decision variables like example √ n where n is a measure of the problem size. [16, p. 94]. 1Context related rules.
- 68. 56 Introduction toTabu search The dynamic rules are defined as the ones where the tabu list length vary throughout the search. For instance a length that randomly or systematically varies between some static lower and upper bound. More intelligent dynamic tabu lists can be used to create a more advanced variation, such as long tabu lists when few improvements can be found. A problem with the dynamic approaches is that they are very problem dependant. One way to make the tabu lists more effective is to make use of the a so-called aspiration criteria. 6.2.3.3 Aspiration criteria When a move is performed and an intity therefore is declaired tabu, this will result in more than one solution being tabu. Some of these solutions being tabu could be of excellent quality, and this is where this aspiration criteria has its strength. The aspiration criteria is introduced to remove moves from the tabu list. The most commonly used aspiration criteria, [16] pp. 98, is called ”Aspiration by Objective”. The idea is to remove solutions which have a better objective value than the currently best known from the tabu list. Further reading regarding aspiration criteria can be found on pp. 100 in [16] and on pp. 50 in [11]. 6.2.4 Longer Term Memory Small term memory can be considered as temporary knowledge. Longer term memory differs from this by encapsulating information from the entire search. In some Tabu search implementations, the short term memory components are sufficient to produce high quality solutions. The use of longer term memory does usually not require very much runtime before the improvements starts becoming visible. The reason for this success in long term strategies is to be found in the modified neighborhoods produced by Tabu search; these may contain solutions not in the original one or combinations of elite solutions leading to even better solutions. According to [11] pp. 93, the fastest method for some types of routing and scheduling problems, are based on longer term memory.
- 69. 6.2 Concepts 57 6.2.4.1Intensification Intensification is a strategy to modify or change the solution in a way that seems to be historically good. The idea in intensification resembles the strategy a human being would make use of. When a part a of solution reappears over and over again, it might be worth keeping this part of the solution and then focus on the remaining part of the solution. Another classical intensification method is the intensification-by-restart method, which takes the best solution so far, and restarts from there, meaning that the tabu list is cleared. [11] pp. 96. 6.2.4.2 Diversification As mentioned earlier in this thesis, one of the main problems with the Tabu search algorithm is the tendency of being to local. To avoid the algorithm being to local, diversification is imposed. The observation is that Tabu search tends to spend most, if not all, of its time in a restricted part of the search space when making use of only short term memory. The consequence with the algorithm being to local is that even though it returns good solutions, it might fail to explore the most interesting parts of the search space. As opposed to other metaheuristics as for example Genetic algorithms where randomization in combining population elements provides diversification to the algorithm, Tabu search has no natural way of diversifying except from the special case where the tabu list is very long. Diversification is created to drive the search into new regions of the search space. One very common diversification strategy is to bring infrequently seen entities into the solution. This approach forces the algorithm into hopefully new region of the search space and thereby improve the solution. [11] pp. 98.
- 70. 58 Introduction toTabu search
- 71. Chapter 7 Solver foundation Whenpresenting metaheuristics it is considered an advantage to present the concepts in abstract terms. Such a presentation however, often leaves much to the reader. This thesis aims to do both an abstract description of the im- plemented metaheuristic and a solid description of the low level necessities in order to implement the metaheuristic. This chapter deals with the latter, and therefore solves a number of smaller problems which will arise in the proposed metaheuristic. Since the algorithms presented in this chapter will constitute the foundation of the solver, time complexity considerations are naturally presented. The fundamental idea behind the proposed algorithm is to think of jobs as marbles and work days as bins. The job of the algorithm is then to throw the marbles, which are lying in a bag, into the bins. Marbles in the bag are unassigned jobs, and when a marble is put into a bin the job is to be handled on that work day. Unfortunatly the marbles change sizes when added to a specific bin, since a technician not only has to handle the job, which takes a constant amount of time, but also has to drive to the location of the job. The magnitude of the change in sizes is therefore dependent on the other marbles in the bin. Section 7.1 describes how the bins are handled, section 7.2.2 elaborate on how the change in marble sizes is calculated, section 7.2 and 7.3 deals with deciding whether a marble fits in a bin, and finally section 7.4 explains how the objective function changes when a marble is moved from one bin to another.
- 72. 60 Solver foundation 7.1Technician plan A technician plan is an abstract concept, which describes when the technicians are at work. Each technician has a calendar which describes when he is at work and when he is at home. The idea is to split this calendar into pieces, each piece being a technician plan. Figure 7.1 illustrates this concept. Figure 7.1: Illustrating how a work schedule is split into technician plans. Chapter 3 introduced assignments, which were a job assigned to a technician at a specific time. Using technician plans, an assignment needs only to be a job to a technician plan, since the technician plan represents both technician and time. In verbal terms one can say, a technician plan is a plan of what jobs a technician need to handle on a specific work day. By introducing technician plans the problem of creating a solution becomes a job-to-technician plan assignment problem, and so it abstracts away from time and technicians. Introducing technician plans entails the advantage that it is, in many cases, equivalent having one technician working two days as to have two technicians working one day. Introducing technician plans is only possible under the assumption that it is unimportant when a job is performed during a day, or at least during the time a certain technician plan encapsulates. The jobs are ordered by creating a route between them, and so this route has to be updated each time a job is either added or removed from a technician plan. The time available is therefore used for two things, that is handling the actual jobs and traveling between the jobs. These are denoted handling time (HT) and transportation time (TT). Figure 7.2 illustrates an example of how the available time in a technician plan can be used.
- 73. 7.1 Technician plan61 Figure 7.2: Illustrating how a technician plan is used for both travel and han- dling of jobs. In this example only just over 50% of the capacity is used. The blue color is illustrating transportation time, green is the duration of the jobs, and white is unused time. 7.1.1 Updating the route As explained in chapter 3 each technician has a homebase which he has to start and end at each day. The route can be thought of as a path in a graph of vertices and edges. Each vertex in the graph is a job location, where the home base is a mandatory start and end location. Each edge is the fastest route between the addresses of two job locations, and the cost of using the edge is the time it takes to drive between the two job locations. Note that the graph is a complete graph and all distances are Euclidean. The route the technician must drive in order to visit all job locations and return to his homabase is a Hamiltonian tour. To be able to fit as many jobs into a technician plan as possible, it is a goal to create a short Hamiltonian tour. Adding a job to the route is done by finding the cheapest insertion between two vertices. Removal is done by removing the node and creating a new edge between the predecessor and succesor in the old path. This algorithm is called the Cheapest neighbor insertion algorithm and is illustrated in figure 7.3. The Cheapest neighbor insertion algorithm will find the optimal Hamiltonian tour, if the graph contains no more than four vertices. That is even though TSP is NP-hard. This is seen by using combinatorics. When the fourth vertex is inserted into the tour, three different insertions and therefore also three different tours, are tested, i.e. one for each pair of neighbors. The number of possible different tours is calculated by choosing a vertex as start and end vertex. Then three other vertices need to be visited which can be done in 3! = 6 different ways. Note that half of these routes can be discarded due to symmetry, i.e. the tour visiting the vertices A-B-C is equivalent to the rout visiting the vertices C-B-A. Therefore the number of possible tours for a route with four vertices is 3 which is the number of different routes tested by the Cheapest neighbor insertion. Cheapest neighbor insertion is optimal for problems not larger than four, since the case with less than four vertices is realized also to be optimal
- 74. 62 Solver foundation Figure7.3: Shows how nodes are added and removed from a path. Note that the graph is complete, but only the used edges are shown. using a corresponding argument. 7.2 Checking legality This section deals with the problem of deciding whether it is legal to assign a certain job to a certain technician plan. That is answering the following question. Given job j and technician plan A, is it legal to assign job j to technician plan A? For a job to be assignable to a given technician plan all the hard constraints, except from the n ASSIGNMENTS constraint, since this constraint dictates a property of a whole solution and not of a single assignment. • The ALLOWED constraint is simply a boolean matrix stating whether an assignment is legal, so this is easily checked in constant time. • Whether the WORKLOAD constraint is satisfied depends on whether there is enough time to handle both the jobs and travel between them. How this constraint is checked, is discussed in section 7.2.1.
- 75. 7.2 Checking legality63 • The ON LOCATION constraint is always satisfied, since a route is created in each technician plan and this route is used in deciding whether the WORKLOAD constraint is satisfied. 7.2.1 Bounding technician plan routes Deciding whether the WORKLOAD constraint is satisfied requires one to cal- culate the handling time, HT, and travel time, TT, as explained in section 7.1. The HT is easily calculated and the assignment is trivially illegal if HT > s, where s is the size of the technician plan. Calculating the true TT requires one to find the optimal tour in a TSP which can be a time consuming task since TSP is NP-complete. Therefore another approach is suggested. The idea is that instead of actually solving the TSP, it might be possible to bound it. The hope is, that in many cases the question can be answered only being aware of the bound values. Let, ˆTT denote the upper bound and let TT denote the lower bound on the transportation time. Then the bounds can be used in the following way: If s < HT + TT then it can be concluded the job cannot be added to the technician plan. If s ≥ HT + ˆTT then it can be concluded the job can be added to the technician plan. By investigating the above equations, it can be concluded that the more tight the bounds are, the more efficient they will work. However, the more tight a bound is, the more computation time the calculation will require. Therefore the next sections will present a number of bounds which takes this time and quality tradeoff into consideration. 7.2.1.1 Upper bound of TT Since TSP is a minimization, any Hamiltonian tour is an upper bound. Recall that next to each technician plan is stored a current Hamiltonian tour which is the route the technician is expected to drive. This route can be used when calculation the upper bound. The idea is to insert the new job location in the current tour using a fast algorithm.
- 76. 64 Solver foundation Theinsertion is done using the Cheapest neighbor insertion. However, recall that the upper bound is used trying to answer yes to the question: Can this job be assigned to this specific technician plan? Therefore the calculation can be stopped as soon as a sufficient cheap insertion is found. In worst case no insertion is found which means, that all pairs of neigbors are tested. The time complexity is therefore linear in the number of jobs already in the technician plan. 7.2.1.2 Lower bound of TT The most used TSP lower bound is the 1-tree, which is also the bound used in this thesis. Here a 1-tree framework will be used to provide two different lower bounds for TSP. These bounds are denoted constant and linear lower bound according to their time complexity. The idea is to keep a Minimum spanning tree (MST) of the current job location next to each technician plan, and then use this as part of the lower bound. Let {v1, ..vk} denote the jobs already in the technician plan, and let v denote the job applying to the technician plan. The 1-tree bound says that the optimal TSP route is no longer the cost of the MST build upon nodes {v1, .., vk} plus the two cheapest edges connecting node v to the MST. Figure 7.4: Illustrates how a 1-tree bound is created. Proof. Any feasible TSP-tour will have two edges that connects node v with the remaining graph. Let these edges be denoted e1 and e2. If e1 and e2 are removed from the TSP-tour, the remaining edges will be a spanning tree, R. The price of the optimal TSP-tour can with the introduced notation be calcu- lated as: length(R) + length(e1) + length(e2)
- 77. 7.2 Checking legality65 Now consider the 1-tree bound. Let the two cheapest edges incident with node v, in the whole graph, be denoted e3 and e4. With this notation the 1-tree bound can be calculated: length(MST) + length(e3) + length(e4) With the correct choice of e3 and e4, both length(e3) ≤ length(e1) and length(e4) ≤ length(e2) can be obtained. Further, length(MST) ≤ length(R). Therefore length(R) + length(e1) + length(e2) ≥ length(e3) + length(e4) + length(MST) which is the 1-tree bound. The constant lower bound is simply to use the MST as a lower bound. Since the cost of the MST is precalculated, the time complexity of this bound is constant. One could argue that this bound is very week, and therefore not worth using since the bound assumes that no extra driving will be necessary in order to handle job v. However, recall that the WORKLOAD constraint also includes handling time which could make this bound efficient. The linear lower bound is the actual 1-tree bound. Since the two cheapest of all the edges that connect node v with the MST need to be found, the time complexity of the linear lower bound is O(k) where k is the number of jobs in the technician plan. The 1-tree lower bound can be further tightened by using the state of the art Held Karp bound. When the 1-tree bound is weak, it is often because some nodes in the MST have large degrees. Recall that the constraint, that each node must have degree two is relaxed in the 1-tree. The idea behind the Held Karp bound is to recalculate the cost on each edge such that edges which connect nodes with high degrees are penalized and edges that connect nodes with low degrees are compensated. Then a new MST can be calculated which hopefully can be interpret as a new lower bound. This is done iteratively. Since the Held Karp bound is an iterative bound, it might require many itera- tions before it gets tight. Recall that the bounds on the TT are supposed to be very fast in order to be efficient in the TRSP framework. Therefore neither the Held Karp bound, nor any other of the lower bounds which require iterations are considered a good idea for the TRSP. Building and maintaining the MST Both of the lower bounds require a MST, and therefore a MST needs to be precomputed. Since the MST contains the job locations of the jobs already in the technician plan, the MST only needs to be updated when a job is added or removed from the technician plan.
- 78. 66 Solver foundation Addinga new node to an existing MST is done by adding the cheapest edge which can connect the new node with the existing MST. Note that adding this edge will result in a new spanning tree, but there is no guarantee that this is an MST. The problem is, that the new node only has degree one in the new spanning tree which might not be optimal. Before the actual insertion algorithm is presented, a number of arguments for justifying the algorithm are given. Let v denote the new node and v1 and v2 denote two nodes already present in the MST. If dist(v2, v) ≥ dist(v, v1) and dist(v, v1) ≥ dist(v1, v2) then the edge (v, v2) is not in the MST. This situation is shown in figure 7.5. This is seen to be a contradiction. Assume that the edge (v, v2) is in the MST then by choosing either (v, v1) or (v1, v2) a cycle containing (v, v2) and either (v, v1) or (v1, v2). In this cycle the egde with the largest cost is removed to obtain an MST. If the edge with the largest cost is (v, v2), the contradiction is obtained. If (v, v2) is not the most expensive edge, a new cycle containing only (v1, v2), (v, v1) and (v, v2). Figure 7.5: Illustrates the near points of v. Let the nodes, which could not be discarded by the above mentioned method, be denoted near points and the edges between the new node and the near nodes be denoted near edges. Then there are no more than 6 near points, which is seen by contradiction. Place 7 nodes with equal distance between each one on the periphery of a cycle. Then note, that the distance between each node is less than the radius of the cycle. The algorithm for extending a MST with one node, first finds the near points and then for each near point, inserts the associated near edge. This results in a cycle found, then the most expensive edge in this cycle is removed. Since
- 79. 7.2 Checking legality67 the number of near nodes can be bounded by a constant, the algorithm has a time complexity of O(k). The pseudocode of the implemented algorithm can be seen in appendix B and rigorous proofs for both correctness and the time complexcity can be found in [20]. The problem concerning removing a job location from a MST is more compli- cated than the adding problem. However, like the adding problem there exists a linear algorithm. Unfortunately, this algorithm requires to keep a geometric structure such as Delaunay triangulation [20]. Further, the time complexity contains some large constants. Therefore it was in a TRSP context considered to be faster to build a new MST each time a job was being removed from a technician plan. To build MST, Kruskal’s algorithm1 is used. Kruskal’s algorithm first sorts the edges by cost. Then the edges are added to the MST one at a time in increasing order. Each edge is only added, if it does not result in a cycle. When implementing Kruskal, two tricks can be used. The first trick is to use Quick- Sort2 to sort the edges. Then a lazy approach where only the edges smaller than the pivot element are sorted recursively, the recursive calls sorting the elements larger than the pivot element are stored in a stack until needed. This is possible since Kruskal in each iteration, only needs the edge with the lowest cost. The second trick is, that the check for cycles is moved into the sorting algorithm so that edges which will result in a cycle are not sorted but simply discarded. This could increase the speed, since not all the sorting is done before starting adding edges to the MST. The runtime of the Lazy-Kruskal’s algorithm is O(k2 · lg(k)), where k is the number of vertices, like the standard algorithm since it is not believed that any of the introduced tricks gives an asymptotic improvement. The pseudocode of the implemented algorithm can be seen in appendix B. The proof of correctness for the Lazy-Kruskal algorithm is similar to the proof of the traditional Kruskal algorithm. I.e after the p’th iteration the p cheapest edges that do not result in a cycle are chosen. Therefore after the k−1 iteration, a complete MST is build. It is certain that for each iteration, no cycle is created since only edges are added to the MST if the two vertices associated with the edge are not members of the same disjoint set. 1[21] page 569 2[21] page 146
- 80. 68 Solver foundation 7.2.2TSP Heuristics If the transportation time bounds does not provide sufficient information to answer the question: Whether it is legal to assign job j to technician plan A? One could determine a good or optimal solution to the TSP and then declare the assignment legal if the tour is sufficient cheap. Note that if the optimal TSP- tour is calculated, the question can be answered with certainty, else a heuristic answer is given. The largest difference between optimal and near-optimal algorithms to TSP, is that optimal has an exponential time complexity and guarantee optimality whereas near-optimal algorithms often have polynomial time complexities, and if a guarantee is given, this is mostly to weak to be used practical. Ergo, a time versus quality trade off has to be made. When TRSP was analyzed in chapter 4, it was concluded that the number of jobs in each technician plan was small which could argue for an optimal algorithm. However, this thesis is developing a system which should be as general as possible, meaning many different clients should be able to use it. Even though the interviewed clients only have a small number of jobs in each technician plan, this does not mean that potential future clients does. Note that the consequence of choosing an optimal algorithm will be an exponential blow up in computational effort within the engine. Therefore, the choice in this thesis will be to use a heuristic where the time complexity can be bounded polynomial. However, the consequense of choosing a heuristic is that the answer to the question concerning time within the technician plan might end up with a false negative. This consequence is accepted. As stated in [15] and [12], the state of the art TSP heuristics are Lin-Kernighan and a number of other metaheuristics. However, a much simpler heuristic, 2- opt, is considered a faster alternative, this can be concluded by the results presented in table 7.1 which is part of the results presented in the downloadable preliminary version of the chapter in [12], pp. 215-310. The quality of the heuristics presented in the table, is based on the Held Karp lower bounds. Since it could be the case that a TSP needs to be solved each time it is checked whether it is legal to assign a job to a technician plan, computational runtimes are weighted higher than quality. Therefore 2-opt, based on the results presented in table 7.1, will be the chosen heuristic to solve instances of TSP in TRSP when bounds does not provide sufficient information.
- 81. 7.2 Checking legality69 Algo.N 102 102.5 103 2-Opt 4.5% 0.03 s. 4.8% 0.09 s. 4.9% 0.34 s. 3-Opt 2.5% 0.04 s. 2.5% 0.11 s. 3.1% 0.41 s. LK 1.5% 0.06 s. 1.7% 0.20 s. 2.0% 0.77 s. Table 7.1: This table provides results on several heuristics for solving TSP, the percent excess the percentive value over the Held-Karp lower bound and the other is the computational time used to find the result. 2-Opt The 2-Opt algorithm was first proposed by Croes in 1958, although the basics of the algorithm had already been suggested by Flood in 1956 [12]. The 2-opt algorithm is a tour improvement algorithm. I.e the input is a Hamiltonian tour and the output is, if the algorithm can find one, a shorter Hamiltonian tour. The idea Floods came up with, was to break the tour into two paths, and then reconnect those paths into the other possible way, see figure 7.6. Figure 7.6: This figure shows the principle of 2-Opt. As seen on figure 7.6, the idea is to take two pairs of consecutive nodes from a tour, here the pairs A & B and C & D. Check and see if the distances |AB| + |CD| is larger than the distances |AC| + |DB|. If |AB| + |CD| distance is the largest, then swap A and C which will result in a reversed tour between those two nodes. The 2-opt algorithm tries all possible swaps. If an improvement is found, the swap is made and the algorithm is restarted. The time complexity of 2-Opt is equal to the number of improvements times the computational effort of one improvement. One improvement can in worst case require O(k2 ), where k is the number of jobs in the technician plan, if no improvement is found and all combinations of swaps are tried. The number of improvements is trickier. It has been proven in [13] that there exist instances and starting tours such that
- 82. 70 Solver foundation 2-optcould find Θ(2k ) improvements which could suggest that no polynomial time bound can be proven for 2-opt. Recall that the input tour given to 2-Opt is generated by the Cheapest insertion algorithm, therefore 2-opt is expected to be fast. No theoretical guarantee for the time complexity is provided here. However, the general recommendation from the Operation Research community is, that 2-Opt is the fastest TSP heuristic so it should be okay. Another approach is simply to stop 2-Opt after a number of improvements, say k. Then 2-Opt can be bounded by O(k3 ). Since this bound is only considered to be of theoretic interest, the TSP are considered to be small and the aim is to provide the best possible solution to the users of this software this bound has not been implemented. The pseudocode of the implemented algorithm is included in appendix B. The idea of the 2-opt algorithm can be improved by instead of dividing the tour into two paths, it could be divided into three paths and then try to connect these, which is called 3-opt, etc. Further heuristics exist for solving the TSP, since 2-Opt is preferred in this thesis, we will not go into further details regarding these. 7.2.3 Accepting or rejecting the legality In the previous section a number of methods for bounding or a finding a tour with low transportation time were presented. The order in which these are used, are described here: • Rejecting that the technician can handle the job using the constant lower bound. • Accepting that the technician can handle the job using the upper bound. • Rejecting that the technician can handle the job using the linear lower bound. • Accepting that the technician can handle the job using 2-opt upper bound. • Rejecting that the technician can handle the jobs since no bound accepted. The above mentioned method is only used when the number of jobs in a tech- nician plan exceed three, since the Cheapest neighbor insertion will provide optimal Hamiltonian tour for smaller problems. As a consequence of this, no
- 83. 7.3 The bilitiesdata structure 71 MST is build until the third job is added to the technician plan. Recall, that the homebase also is part of the vertices, so adding the third job results in four vertices in the technician plan. 7.3 The bilities data structure Section 7.2 described a procedure to use when deciding whether an assignment was legal. This section will describe a datastructure, which uses this procedure to store information about the legality of all assignments in a given solution. When designing a Tabu search heuristic, a crucial parameter is the choice of neighborhood and candidate list. An unwise choice can ruin the efficiency of the entire algorithm. In most cases a clever neighborhood and candidate list are derived from the objective function. Unfortunately, since the soft constraints are not known a priori, it is not possible to derive effective neighborhoods and candidate lists from these constraints. A natural choice is to use the hard constraint, since the kind of hard constraints that the algorithm can solve are known up front. This section will present the necessary tool in creating efficient neighborhoods and candidate lists. Three concepts are introduced called possibilities, feasibilities and neighborbil- ities. The idea is to keep information about which assignments are legal in different situations. The following three sections will describe each of them in more details. 7.3.1 Possibilities The concept of possibilities describes the possible assignments for a given prob- lem. An assignment is said to be possible, if it is legal in an empty solution. This information can be saved in a data structure similar to the one shown in example 7.1. The idea is, that each job has a list of technician plans, which it can the assigned to. Likewise, each technician plan has a list of jobs, which can be assigned to it. This implies the following important property; if and only if a job j has technician plan A in its possibility list then A will have job j in its possibility list. The definition of a possible assignment implies, that the possibilities data struc- ture is a static structure. The data structure can therefore be computed in the
- 84. 72 Solver foundation beginningof the optimization, and can be kept unchanged when the solution changes. Example 7.1 This example shows a data structure containing the possibilities information for a given problem P. The problem contains two technician plans (A and B), and four jobs (j1, ..j4). All assignments are possible except from job j2 which cannot be assigned to A. The possibility data structure is shown in figure 7.7. Figure 7.7: The possibilities data structure for the problem P. The reason why job j2 cannot be assigned to A could be that the technician associated with A does not have the required skills, or that there might not be an overlap in time between A and the time window of j2. However, when the possibility data structure is constructed, the real life reason does not matter since the possibilities data structure contains sufficient information to do the optimization. 7.3.2 Feasibilities When a job j is added to a technician plan A, then the possibilities data struc- ture no longer represent the legal assignments. There are two reasons for this. The first reason is, that job j can only be present in a single technician plan at a time and hence can not be put into another one. The second reason is, that the legal assignments of other jobs might change. This happens since the available capacity of A change when j is added. The concept of feasibilities is introduced to keep information about the feasible
- 85. 7.3 The bilitiesdata structure 73 assignments in a given solution. A feasible assignment is one that is legal in the solution at hand. The feasibilities data structure is a dynamic data structure that is being updated each time the current solution changes. A change can either be that a job is assigned to a technician plan or that a job is removed from one. Example 7.2 This example is a continuation of example 7.1. i.e. the problem to be solved is P. Job j4 is assigned to B and the feasibilities data structure is updated. The data structure is updated in two ways. First, the feasibilities of j4 needs to be emptied since j4 is now assigned and so it is not legal to assign it to another technician plan. Second, each job in the feasibilities of B, which can not be assigned to B anymore should be removed from the list. The updated data structure is shown in figure 7.8. Figure 7.8: The feasibilities data structure after assigning j4 to B. The figure shows how the feasibilies of j4 is now empty. It is also seen that j1 and j3 can no longer be assigned to B. j3 is still assignable to B, because this assignment does not violate the WORKLOAD constraint. An important property of the feasibilities data structure is, that each time a job is assigned then the size of the data structure decreases. Further, when a solution is feasible, which implies that all jobs are assigned, then the feasibilities data structure will be completely empty. The feasibilities data structure are therefore suitable for finding assignments for unassigned jobs, i.e. getting a feasible solution. However, it is not suitable for moving from one feasible solution to a neighbor solution.
- 86. 74 Solver foundation 7.3.3Neighborbilities Section 7.3.2 introduced feasibilities, which are suitable for getting into feasible space. This section will introduce the concept of neighborbilities, which can be used when moving between neighbor solutions. The aim is to develop a data structure that can, once all jobs are assigned, hold information about which of the already assigned jobs that can be moved to other technician plans. The data structure will, in this way, contain information about the neighbor solutions for a given solution3 . The data structure is denoted the neighborbilities data structure. Example 7.3 shows how the neighborbilities are constructed. Example 7.3 This example will demonstrate how to update the neighborbilities data structure when a job is assigned to a technician plan. The assignment from example 7.2 will be used on problem P. Job j4 is assigned to B and the neighborbilities data structure is updated. Figure 7.9 shows neighborbilities after this assignment. Figure 7.9: This figure shows the concept of neighborbilities. It is noted that, like the update for the feasibilities data structure, the neighbor- bilities data structure has removed jobs j1 and j3 from B. Further, job j4 is removed from B, since j4 can not be assigned twice to B. However, j4 is still present in A, which can be interpreted as if j4 was removed from technician plan B then it would be legal to assign it to A. 3This statement is of course only true because of the way the neighborhood is going to be defined in section 8.2.2.
- 87. 7.3 The bilitiesdata structure 75 7.3.4 Relations between the bility data structures So far three different data structures have been presented. As indicated in the naming and previous examples of these data structures they have a lot of similarities. Actually, they are so similar that they can be presented as only one data structure. The idea is to build only the possibilities data structure and then maintain both the feasibilities and neighborbilities in the same data structure. This is possible, since the feasibilities are a subset of the neighborbilities, and the neighborbilities are a subset of the possibilities. A bilities data structure is defined to be a subset of another bilities data structure if and only if the elements in each of the lists in the first data structure are a subset of elements in the corresponding list in the other data structure. The neighborbilities are a subset of possibilities, since the possibilties contains all feasible assignments. The feasibilities are a subset of the neighborbilities, since the neighbilities have both the assignments of the feasibilities, as well as those from a technician plan to another technician plan. The feasibilities are simply moves from ”nothing” to a technician plan. Example 7.4 This example demonstrates how all the bilities data structures can be maintained in one data structure. The problem P and the move j4 to B from the three previous examples are reused. The data structure is shown in figure 7.10. Figure 7.10: The combined bilities data structure after adding j4 to B. The blue nodes are possibilities only, the red one is a possibility and a neighborbility and the green ones are all three possibilities. The figure shows how the pointers go from the smallest subset to the largest. In this way one has to traverse a minimum amount of nodes to find the desired
- 88. 76 Solver foundation datastructure. 7.3.5 Time complexity of the bilities data structure oper- ations The bilities data structure is going to be a corner stone in the algorithms pre- sented in section 8, and so the running time is naturally of great importance. Three different operations will be analyzed. This is building the data structure, adding a job to a technician plan and removing a job from a technicain plan. The three operations are very similar in the way that they are all using the procedure described in section 7.2. The only difference is how many times it is used and in which kind of state the solution, corresponding to the bilities data structure, is in. The procedure will be denoted ϕ in the following paragraphs. Building the data structure The data structure will only be build from scratch when the solution is empty. Thus the time complexity of ϕ will be O(1), since either the constant upper or lower bound can be applied. Building the initial possibilities requires one to perform ϕ n · p times resulting in a time complexity of O(n · p) where n is the number of jobs and p is the number of technician plans. The building requires O(n·p), since it has to be tested whether every assignment of a job j to a technician A is a possibility. Adding a job to a techncian plan When a job is added to a technician plan each of the jobs in the technician plan’s neighborbility list needs to be checked if it is still legal to assign the job to the technician plan. In worst case the neighborbility list is the whole possibility list which in worst case is all the jobs. Therefore a total work of O(n · ϕ) i required. Removing a job from a technician plan When a job is removed from a technician plan, each job which is in the possibility list and not in the neighborbility list, needs to be checked if the assignment is
- 89. 7.4 Delta evaluation77 now legal. This is in worst case the whole possibility list which in worst case is all jobs. Therefore a total work of O(n · ϕ) is required. 7.4 Delta evaluation Delta evaluation was introduced in chapter 6 as a way for Tabu search to quickly move around in the solution space. This section will focus on how each soft constraint is delta evaluated. The purpose of a delta evaluation is to evaluate the change in a solutions objec- tive value, when a change is made to the solution. As described in section 7.1 a solution is split into a number of technician plans. A consequence of this choice is that there exist only two possible changes that can be made to a solution; to remove a job from a technician plan or to add a job to a technician plan. If v is the objective of a specific solution x then the delta value ∆v is calculated as shown in 7.1. ∆v = ∆vout + ∆vin (7.1) vout is the value of x after removing a job from x and vin the value of x after adding a job to x. It is therefore necessary that the delta value of each soft constraint can be calculated when a job is added and when a job is removed. In the following descriptions of the delta evaluations the job in play is called j and technician plan A. 7.4.1 Minimize driving This soft constraint minimizes the total transportation time used by technicians in driving between jobs. The new route cost is calculated by removing j from the route between the jobs in A. The delta value is the value of the old route minus the value of the new route. When a job is added the new route cost is calculated by adding j to the route between the jobs in A. The delta value is the value of the old route minus the value of the new route. The time needed for delta evaluation is the time needed to compute the value of the new route. The delta evaluation is constant, since there are a constant number of jobs in a technician plan.
- 90. 78 Solver foundation 7.4.2Maximize technician to customer priority The idea of the soft constraint is that each assignment of a job j for a technician i is given a ”tech to customer” priority pij. The goal is then to maximize the points obtained by letting preferred technicians handle preferred job. The objective value is calculated by calculating the value of each assignment in each technician plan. These values are then added together. The delta value of a move is simply equal to the value of the assignment in question. The is delta value equal to pij when assigning a job and equal to −pij when removing a job. Both evaluations are done in constant time. 7.4.3 Minimize job to time penalty The delta evaluation is simply done by either adding or removing the penalty for having a job in a technician plan, when a job is either added to a technician plan or removed from one. This is done in constant time. 7.4.4 Maximize robustness If the removal of a job creates space for one or more standard jobs, then the robustness of the shifts it is a part of, has to be changed. If the removal of a job gives space for two new standard jobs and the technician plan is part of two shifts, then one point is added to each shift and the robustness of the shift is recalculated. It is a fair assumption that a technician plan is only part of a constant number of shifts4 , and so the delta evaluation is constant. Example 7.5 shows the calculation of a delta value. Example 7.5 The basis of this example is the solution shown in figure 7.11. A job j is added to the technician plan for technician 1 on day 1 and 2. This addition removes space for 1 standard job, and so the robustness of shift 1 and shift 2 have to be decreased. The robustness of shift 1 is calculated like this:√ 2.5 − 0.5 = 1.41, and shift 2 like this: √ 1.5 − 0.5 = 1. The total change in robustness is therefore (1.41 − 1.58) + (1 − 1.22) = −0.39. 4Since shifts are supposed to last a day and people have to sleep.
- 91. 7.4 Delta evaluation79 Figure 7.11: Illustrating the calculation of the robustness of a solution. The robustness in this example is 3.81.
- 92.
- 93. Chapter 8 Solver overview Thischapter will give an overview of the proposed solver for solving instances of TRSP. Chapter 4 made it clear that a meta heuristic was the right choice for solving these problems. The solver will use the fundamental idea from chapter 7 as the foundation, meaning every component of the meta heuristic will be based on technician plans and the bilities data structure. The components of the meta heuristic will make use of a wide range of the ideas introduced in chapter 5 and 6. The chapter starts by introducing the main components of the solver. Section 8.1 desribes how a feasible solution is constructed, while section 8.2 explains how such a solution is improved. Sections 8.3 and 8.4 introduces two methods for further exploration of the solution space. Finally section 8.5 gives an overview of how these components interact. 8.1 Construction This section describes an algorithm, which solves the problem of how to con- struct a feasible solution. As described in section 4.3 it is not reasonable to solve this problem using an optimal algorithm, therefore this section will describe a heuristic.
- 94. 82 Solver overview Theheuristic will use the concept of feasibilities as introduced in section 7.3. As one might remember feasibilities is a way of storing which of the unassigned jobs can be assigned without making the solution infeasible. The basic idea in the heuristic is to assign the jobs on at a time by assigning them to one of the technician plans in the feasibilities of each job. This approach raises three questions: • In which order should the jobs be assigned? • Which technician plan should the job be assigned to, when a job has more than one feasibility? • What happens if a job does not have any feasibilities? 8.1.1 Assigning jobs to technician plans The assignment of jobs to technician plans is done using a greedy approach. Jobs are ordered using a priority queue. This queue prioritizes jobs with few feasibilities before jobs with many feasibilities. The idea is that a job, which only has a few possible technician plans left in the feasibilities list, is critical in the sense that, if it is not assigned now, then it might end up with no possible plans to be assigned to. Now that a job has been chosen one has to choose a technician plan from the jobs feasibilities. The plan which is the most critical in terms of feasible jobs is chosen. A plan with few assignable jobs is said to be less critical than a plan with many feasible jobs, since assigning a job to such a plan will remove few feasibilities from other jobs. The priority queue is updated every time a job is assigned to a plan, since assigning a job will change the feasibilities. 8.1.2 Running out of feasibilities Using the described approach, a job might end up with no feasibilities at all. As described in section 7.2 there are two fundamental properties, which have to be satisfied for a job to have a technician plan in its feasibilities.
- 95. 8.1 Construction 83 8.1.2.1ALLOWED The first property originates from the ALLOWED constraint. As explained in section 4.3 satisfying this constraint yields a packing problem. The greedy approach explained above is an attempt to solve this packing prob- lem. It might however not be sufficient to prevent a job from running out of feasibilities. A backtrack approach is introduced. Backtracking The idea in the backtrack approach is to force the unassignable job into a technician plan by removing some of the jobs already present in the technician plan. The jobs which got removed are then put back into the priority queue. The jobs to remove are chosen in the following way: 1. If a technician plan with n jobs exists, where each of the n jobs have a neighbourbility and removing the n jobs will make room for the new job, then choose that technician plan and remove those n jobs. This is a good idea, since the n jobs can be replaced without putting other jobs back into the priority queue. If more than one technician plan with this property exists then a random one is chosen. 2. If the first attempt at finding a plan fails, then an approach based on how many times a job is forced into a technician plan is used. The approach is a min-max strategy and choose n jobs to be removed the following way: For each technician plan A a set of n jobs are chosen which can make room for the new job. The job which has been forced into a technician plan the most times in each set is named ˆA. Then the job in the set of ˆA’s with the fewest times forced is chosen. The set of n jobs corresponding to the chosen ˆA are removed. In the case that a tie between two or more ˆA’s occur then the algorithm will make use of the feasibilities. The job with the fewest possibilities among all the job feasibilities for all the tied technician plans is chosen as the job to be removed. The second approach described above choose a set of n jobs from each tech- nician plan. Two methods for choosing the n jobs from each technician plan are proposed. The first method chooses the n jobs which have been forced into technician plans the fewest times. The second method makes use of a random weighted linear function instead of being deterministic.
- 96. 84 Solver overview Abanning approach is introduced to prevent the algorithm from spending to much time adding and removing the same jobs over and over again. This is both helpful if it is simply hard to find a feasible solution, and if the problem is infeasible, since the algorithm would otherwise use infinite time. The idea is simply to stop putting jobs back into the priority queue if they have been forced into technician plans a specific number of times. 8.1.2.2 WORKLOAD The second property is whether there is enough time left in a technician plan for a job to be carried out. The heuristic described so far does not take travel into account except from just updating the feasibilities. Because of this a job might end up with no feasibilities because the technicians simply use to much time driving around. An attempt to solve this problem is by using the local search heuristic being introduced in section 8.2 using just distance as the objective function. The idea is that the heuristic will minimize the distance travelled and thereby create more space in the technician plans for new jobs. The local search heuristic performs poorly when there is not enough space in the technician plans for it to move the jobs around. Because of this it is better to minimize the distance travelled before the technician plans get too full. Two ways of deciding when to minimize the travel distance are introduced: • When the number of completely empty technician plans become less than a certain threshold. This threshold can be both a static number of technician plans or a percentage of the total number of technician plans. • When a certain percentage of total time in all technician plans is used for travelling and handling the jobs. The construction heuristic mimics the behavour of semi-greedy approach de- scribed in section 5.5. The heuristic introduced in this section is greedy when assigning jobs and random when choosing which to unassign when backtracking.
- 97. 8.2 Optimization 85 8.2Optimization The construction heuristic proposed in section 8.1 does not consider the ob- jective function at all. An algorithm that can optimize solutions is therefore needed. A study of different optimization heuristics was made in section 5, and the conclusion was, that Tabu search was the best choice for the problem at hand. As described in section 6.2 one needs to define several properties of a Tabu search heuristic for it to become effective on a specific problem. A definition of the search space, the neighborhood, the candidate lists and the tabu list is needed. 8.2.1 Search space The search space is restricted to only contain feasible solutions. The construc- tion heuristic is, as explained before, used to construct feasible solutions. The idea is that Tabu search should stay in the search space of feasible solutions. 8.2.2 Neighborhood As mentioned earlier the search space is restricted to only contain feasible solu- tions. This choice restricts the neighborhood in the sense that all neighbors of a solution must be feasible solutions. A neighbor solution is defined as a solution for which a single job has been moved from its initial technician plan in the original solution to another technician plan in the new solution. Moving a job like this is defined as a neighbor move. These neighbor moves have to be legal so that the search stays inside the feasible search space. This is achieved by using the neighborbilities described in section 7.3, since these lists contain information about legal moves. 8.2.3 Candidate list Candidate lists are used to restrict the neighborhood and thereby control how the search moves around in the feasible search space. A candidate list is a set of neighbor moves. The general idea is to focus on a single technician plan at a
- 98. 86 Solver overview time,creating neighbor moves with focus on this plan. Two different methods for creating a candidate list while focusing one a specific technician plan ˆTP are proposed: • A list containing each legal neighbor move, where a job is moved from an- other technician plan to ˆTP. This candidate list is called the In candidate list. • A list containing each legal neighbor move, where the job is currently in ˆTP and moved to another technician plan. This candidate list is called the Out candidate list. The Out candidate list has the side effect that one might force the search to ruin a good technician plan if such one is chosen as ˆTP. A third possibility is therefore to extend the Out candidate list to focus on two or more technician plans at a time minimizing the risk that all of these are good technician plans. The problem of choosing which technician plan to use in creating the candidate list is still unanswered. Two approaches are given: • A deterministic approach which cycles through the technician plans one at a time. • A non-deterministic approach which makes use of a linear weight function on the number of times each plan has been chosen for a neighbor move. The highest weight is given to the plan with the fewest moves. Another idea is to switch between the different methods for creating candidate lists. Two ideas are proposed: • A deterministic approach, which first performs an Out on a technician plan to remove a job, and then an In to insert a new one. A problem with the deterministic approach might be that the number of jobs in technician plans ends up being more or less static. • A non-deterministic approach is suggested which keeps performing the same method for creating dandidate lists a certain number of times, and then switches to another one. The number of times to use a certain method is calculated using a poisson distribution.
- 99. 8.2 Optimization 87 8.2.4Tabu list When choosing a tabu list one has to make two design choiches. That is, which entity is chosen to be made tabu and for how long should this entity be tabu. An entity is made tabu each time a neighbor move is performed, i.e. the entity has to originate from such a move. In the following a move is job j1 moving from technician plan A to technician plan B. The following entities are proposed, ranging from the more restrictive to the less: 1. Making technician plans tabu. It would be tabu to move jobs to or from A and B. It could also be less restrictive as for example just tabu to move jobs from B. 2. Making the job tabu. I.e. j1 is not allowed to be moved. 3. Making the reverse move tabu. That is, it is not allowed to move j1 from B back to A. As tabu length one could imagine having a constant, quadratic or linear tabu length. 8.2.5 Intensification Three methods for intensifying the optimization are proposed: • Intensification could be applied to the final solution of a tabu search by applying a Hill climbing from that solution. This would eliminate obvious improvements from the solution returned by Tabu search. • Clearing the tabu list and starting from the best known solution is also a way of intensifiyng the search. This is what is called a restart. • Picking a set of the best technician plans and taking these out of the optimization is also an intensification. This would help the search focus on the parts of the solution that needs improvement.
- 100. 88 Solver overview 8.2.6Stop criteria One needs to define a criteria for when to stop the Tabu search and try some other optimization scheme. Time is not a good measure, since the criteria should depend on the available processing power. Another mediocre measure is the gradient, since ”not performing that well any more” is hard to define, when the magnitude of the numbers in play can vary. The proposed criteria is to use the number of iterations since an improvement was last seen. The number of Tabu search iterations since an improvement is highly correlated with the problem size. The following stop criteria attempts to compensate for this: x > c · √ a · b (8.1) where c is a constant, x is the number of iterations since an improvement, a is the number of technician plans and b is the number of different candidate lists. The notion of a round is introduced. The idea of a round is that it should be equal to letting the search go through each technician plan trying each candidate list. The criteria incorporates a and b, since this is a good measure for the size of a round. One might think simply a · b would be enough, but since the search makes use of tabus this might not be enough, hence the introduction of c. The square root has been chosen, since tests have shown that this mimics the rounds idea pretty well. Determining the value of c is the subject of section 11.2.3.1. 8.3 Diversification As described in 6.2.4.2 diversification is used to move the local search into areas of the search space which it would otherwise not be able to get to. Two ways of diversifying are proposed: • Remove the n jobs which have been used the least in neighbour moves from the solution. • Remove all jobs from the solution. Removing jobs will make the solution infeasible so the construction heuristic described in section 8.1 is used to get back into the feasible solution space. A banning strategy is used to prevent jobs from simply being added back into the same technician plans as before. The banning strategy consists of three rounds. In each round the banning gets less restrictive until the last round where nothing is banned.
- 101. 8.4 Merging 89 •The first restriction is to disallow adding a job j1 and a job j2 being added to the same technician plan, if j1 and j2 were in the same technician plan in the original solution. • In the second round the restriction is that a job cannot be added to the same technician plan as in the original solution. 8.4 Merging The general idea in solution merging is to identify the good part of two or more solutions, and merge these parts together. This idea is related to the main idea behind genetic algorithms, which were described in section 5.3. The goal of the merge is twofold: • The merge will hopefully create a solution with a high objective value, or at least a solution which is easy to optimize into such one. • Hopefully the merge will create a solution which will bring the optimiza- tion into a new local optimum. The goal is that it should work as a diversification method, which diversifies into a high objective value part of the solution space. The next paragraphs will look into how the good part of a solution is identified as well as how these parts are merged together. As explained in section 7.1 a solution consist of a number of technician plans. These technician plans are a natural choice as the way of dividing a solution into distinct parts. The goal is to identify the good technician plans in each of the solutions and make a new solution with these plans. The technician plans are chosen as the way of dividing a solution since the value of a solution is the sum of the values of the technician plans. That is, if the technician plans with high value in one solution can be merged with the high value technician plans from another solution, then one will end up with an even higher valued solution. One cannot be indifferent about which technician plan a job is located in. The reason for this is, that there might be both a job-to-technician priority and a job-to-time priority, which connects the job to the specific technician plan. The combination of jobs can also be crucial, since there might be a job-to-job priority. An example of this is distance travelled. The main insight is that a solution gets value from
- 102. 90 Solver overview havingspecific combinations of jobs located in specific technician plans, so when merging solutions it is important not to alter the technician plans. A problem that has not been discussed yet is the dependency between technician plans, as seen in the robustness constraint. This type of soft constraint gives value to the solution only when there is a certain relationship between the tech- nician plans. This constraint is therefore hard to take into consideration when choosing the good technician plans. The reason is that the proposed solution merging assumes that technician plans are independent from eachother, because otherwise it would not be possible to merge plans from different solutions. The consequence is that the solution merging proposed in this section will not take this type of soft constraint into account when choosing which plans are good and which are bad. Thus solution merging will not work well, if this type of soft constraints is of high importance. Another problem with this approach is that a job is only allowed once in a solution. If the good technician plans in two solutions contains the same jobs, then the merge will not result in a feasible solution. This problem is solved by prioritizing the technician plans, adding them to the new solution one by one while skipping those with jobs that have already been added. Two approaches to the prioritization of technician plans are proposed. The two approaches share the common idea of a relative technician plan value. The problem with using the absolute value as a measure for the ”goodness” of a technician plan is that there can exist penalty soft constraints, as explained in section 7.4. These soft constraints will end up giving empty technician plans the most value. In an abstract sense the technician plans that we would like to end up with in the merged solution are the plans which are also present in the optimal solution. Relative value tries do this by giving a technician plan value, whenever it improves the value of the solution, not when the technician plan itself gets better. In this way technician plans which ”sacrifice” themselves to make the whole plan better will get a high relative value. It seems intuitive that a good solution will contain these kinds of technician plans. The relative value is calculated by keeping track of a value for each job in a solution, while the solution is being optimized. Each time a job is moved from one technician plan to another that move is delta evaluated. This delta value is how much moving that job changed the value of the solution. The delta value is added to the jobs total value each time a move is made. The relative value of a technician plan is simply the sum of the values of its jobs. The two approaches to technician plan prioritisation are explained:
- 103. 8.4 Merging 91 •All technician plans from each of the solutions are put in a priority queue. In this queue they are prioritized using the following linear combination priority = wabs · vabs + wrel · vrel, where w is a weight and v is the value of the technician plan. This approach is illustrated in figure 8.1. A problem with the first prioritization is that solutions can dominate each other and this results in the fact that no merging will take place. • The second approach tries to fix this by having the solutions in a round- robin queue, and then picking the best technician plan from the head of the queue one at a time. The approach is illustrated in figure 8.2. Figure 8.1: Illustrates how two solutions are merged into one. All technician plans are put into a single priority queue. The feasibility algorithm is used to add jobs into the solution that remain unas- signed after the merge. 8.4.1 Intensification The purpose of solution merging is to find parts of solutions, which have a chance of being in a good or optimal solution. It is therefore important not to alter these technician plans when getting into feasible space and when a local search is applied to the merged solution later on. This is avoided by not letting the two algorithms change the technician plans which were created in the merge. Merging too much into a solution will in this way result in mediocre technician plans being kept in the merged solution. This is avoided by introducing a cap on the amount of plans to be merged, so that only the best plans are reused.
- 104. 92 Solver overview Figure8.2: Illustrates how two solutions are merged into one. A round-robin approach is used so that the solutions switch turns. 8.5 Solver flow The main idea is to let the solver switch between two states. One where the solver generates new solutions, and one where these solutions are merged into, hopefully, better solutions. Figure 8.3 illustrates this approach. New solutions are generated using the diversification component. Diversification is used to get into new unseen parts of the search space, and thereby getting the optimization to find new solutions. Solution merging is done, when a sufficient amount of solutions have been saved. Each of the two states consists of a loop, which is illustrated in figure 8.4. First a feasible solution is constructed, where after it is optimized. The optimized solution is saved, and diversification or merging can then be used to get the solver into a new part of the search space.
- 105. 8.5 Solver flow93 Figure 8.3: This figure explains how the solver switches between the diversifi- cation state and the merging state. 8.5.1 Choosing the set of solutions Diversification is used to generate an initial set of solutions, which will be de- noted first generation solutions. Merging two or more first generation solutions will result in a second generation solution etc. One has to be careful when other than first generation solutions are used in merging depending on how much relative value is weighted in the linear com- bination used to prioritize technician plans. The reason for this is, that plans which were banned after a merging will not recieve any relative value. This happens because the jobs, which are the source of relative value, are not moved in these plans. These banned technician plans, which were the best plans in the initial merging, will end up being mediocre in following merges. In this way good technician plans will not be inherited to the resulting solutions of these mergings. Two solutions are proposed: • Only merge first generation plans. This requires ”new blood”, i.e. new first generation solutions, from diversification. Doing every combination of x solutions from a set of n solutions would imply n x combinations, until new blood would be needed. • Let merged solutions inherit banned plans explicitly. This results in more and more of a solution being banned ending in everything being banned.
- 106. 94 Solver overview Figure8.4: Illustrates a loop in one of the two states.
- 107. Chapter 9 Practical extensions Thischapter explains extensions which are made to be able to solve practical problems. Section 9.1 explains how very large jobs are added to the solution. Section 9.2 suggest how to handle infeasible problems. In 9.3 an algorithm for dealing with changes to the problem definition is suggested, and section 9.4 explains how to deal with forced assignments also known as red jobs. Some of the extensions cope with the assumptions from section 3.1. 9.1 Large jobs The concept of technician plans were introduced in section 7.1. Problems arise whenever the job duration of a job is larger than the capacity of a technician plan. This situation was one of the assumptions stated in section 3.1. The reason why large jobs challenge the model is that they, when split into sev- eral technician plans, create a dependency between the plans. This dependency ruins how the construction- and tabu search algorihtms work. The first thing one has to do to solve this problem, is to decide which jobs are large and which are small. The intuition would be to just define jobs large if the are larger than the capacity of some technician plan. The technician plans
- 108. 96 Practical extensions generatedfor a specific problem can have different capacities, and this can result in one having arbitrary many jobs only assignable to a single technician plan. The suggested approach, is to define a job as large if it is true that it is larger than a specific percentage of the technician plans; a 0.8 fractile seems to be a good choice. The idea is that for a job to be small it has to be small enough to be able to be moved around between most of the technician plans. This will ensure that the construction algorithm and tabu search will be able to move small jobs around in most of the technician plans. 9.1.1 Scheduling large jobs The general idea is to schedule large jobs before starting the scheduling of the small jobs. Then the technician plans used by the large jobs are removed from the solution before assigning small jobs. A large job is assigned by splitting it and assigning it into as many sequential technician plans as needed. It is not a problem that these technician plans are dependent on each other since they are removed from the solution when the small job scheduling begins. The actual algorithm for scheduling the large jobs is using a greedy approach. A greedy approach is feasible since it is assumed that the number of large jobs is small. I.e. scheduling the large jobs in a bad way will not result in a bad final solution since there are only few of these. Two different greedy algorithms are suggested. The value of each possible as- signment of a large job is calculated in both algorithms. The large jobs are then added to a priority queue prioritized using these values. The difference between the algorithms lies in how the jobs are prioritized using the values. • The first algorithm simply prioritizes the job with the highest valued as- signment first. The heuristic is denoted Best value selection. • The second algorithm prioritizes the job with the largest difference be- tween its best two assignments first. The idea is that the best assignment for a job should be used, if the second best is significantly worse. This heuristic is denoted Largest differrence selection. The intuition of the Largest difference selection is that, if one only consider the next assignment, one might lose the change of later assigning a job which would benefit from being assigned to that technician plan.
- 109. 9.2 Infeasible problems97 9.1.2 Solver flow with large jobs The greedy approach proposed in the previous section does not take the small jobs into account when scheduling the large jobs. It might therefore be a good idea to try different assignments of the large jobs, and optimize the small job scheduling for each of the sets of assignments of large jobs. Figure 9.1 illustrates this approach. Figure 9.1: Illustrating how the flow of the solver when having large jobs. The right node encapsulates figure 8.3. 9.2 Infeasible problems There can be two explanations to why the construction algorithm is unable to find a feasible solution. • There does not exist a feasible solution. • The construction algorithm is not capable of finding it, or it has not been given enough time. It is in general as hard to determine if there exists a feasible solution as it is to find the optimal one. A consequence of this is, that there is not any difference between the two cases from a practical point of view. Infeasible problems can be dealt with in two ways. Either one can just give up and tell the user that the problem is too hard, or one can relax a hard constraint and then optimize this relaxed problem. The second proposal is chosen, and so one has to determine which hard con- straint to relax. The best practical choice seems to be to relax the n ASSIGN-
- 110. 98 Practical extensions MENTSconstraint, such that all jobs does not have to be assigned. Other suggestions could have been to make the job duration shorter or transporta- tion time smaller, but these relaxations would create inpractical solutions. One could also use a larger horizon and thereby get more technician plans. This might however not solve the problem, since the trouble might be a hard packing problem in the early part of the optimization period. Letting the user of the algorithm know that the problem was hard, and give a list of the unassigned jobs seems like a more practical choice. 9.3 Changes to the problem definition The problem definition might change as emergency calls arrive and new jobs are created, when technicians call in sick etc. Since there possibly already is a solution to the old problem without these changes, it seems quite intuitive that some of this solution could be used as basis in solving the new problem. Reusing the old solution will hopefully give the new search a good starting point. As explained in section 3 the final algorithm will end up outputting a list of assignments. The idea is, that this list of assignments should be parsed back to the solver together with the new problem definition. The challenge is then how to merge the new problem definition with the solution to the old problem. The merge happens by first creating an empty solution to the new problem definition. For each assignment in the old solution there is then made an attempt at adding the assigned job to the proper technician plan in the newly created solution. In this way jobs assigned to sick technicians will get rejected, and newly created jobs will be added to the pool of unassigned jobs. 9.4 Red jobs As explained in section 2.5 a dispatcher needs the option to force a specific assignment. These forced assignments are defined as red jobs. Red jobs are handled by splitting the technician plan in which the job is situated. The end address of the early technician plan and the start address of the late technician plan is set to the job location. Figure 9.2 illustrates a split. Splitting a technician plans changes the location of where the route either starts or ends. This changed the problem of creating a route from being a classic TSP
- 111. 9.4 Red jobs99 Figure 9.2: Illustrating how a red job splits a technician plan in two. problem to a variant where the route should end at a node different from the start node. This problem is overcome be adding an edge between the end node and the start node with cost 0 and changing the route algorithms. Recall that the job locations in each technician plan are used for two different purposes, namely the current Hamiltonian tour and the MST. First, the algorithm for the MST does not need to be changed since the new edge will always be chosen to be an edge in the MST since it the cheapest edge in the graph. Second, both the Cheapest neighbor insertion and 2-opt are changed so it is not allowed to remove the new edge from the Hamiltonian tour.
- 112.
- 113. Chapter 10 Implementation This sectiondescribes implementation specific topics. Section 10.1 describes two data structures used in the solver. Section 10.2 describes how extendability has been used to make the solver useful for as many Dynamics AX customers as possible. Section 10.3 focuses on how the solver makes use of the compu- tational power at its disposal, while section 10.4 suggests improvements to the implemented solver. Section 10.5 describes how the solver speeds up sequential runs, and section 10.6 describes the integration with Dynamics AX. 10.1 Data structures Throughout the description of the presented metaheuristic there has been a need for several data structures. Most of these have been elementary data structures such as lists, arrays and hash tables. When such are needed the .NET Base Class Library data structures are used. Two data structures which are not available in this library are needed. These are a priority queue and a disjoint set. The computational complexity of these two data structures are analysed using amortized analysis. Section 10.1.1 gives a short introduction to this type of analysis.
- 114. 102 Implementation 10.1.1 Amortizedanalysis Amortized analysis is often used instead of worst case analysis when analysing the complexity of a data structure. The difference between the two types of analysis is that worst case analysis analyzes one operation on the worst instance of the data structure, whereas amortized analysis analyzes the worst case run- ning time over a number of operations. Amortized analysis can be used to show that the average cost of an operation is small, even though a single operation in the sequence might be expensive. The idea is that work on the data structure can be prepaid and then saved for later use. Example 10.1 One element is inserted in a list. The asymptotic time required to do this is O(1). However, the asymptotic time to insert one element in a list and save O(1) work for later is also O(1). Then when n elements are inserted in the list, O(n) work is prepaid. This prepaid work can then be used to run through the list O(1) times. The prepaid work is stored in a potential function Φ, which is a function that maps the instance of the data structure D to a real number. Let, ci denote the real cost an operation i and let ˆci denote the amortized cost of operation i. Then the amortized cost of operation i is given by: ˆci = ci + ∆Φ(Di) = ci + Φ(Di) − Φ(Di−1) (10.1) Therefore the amortized cost of n operations are: n i=1 ˆci = n i=1 (ci + Φ(Di) − Φ(Di−1)) = n i=1 ci + Φ(Dn) − Φ(D0) (10.2) The last equation in 10.2 is true since the series n i=1 Φ(Di) − Φ(Di−1) is a telescoping series. Note that if Φ(Dn) − Φ(D0) ≥ 0 then n i=1 ˆci ≥ n i=1 ci, which says that the amortized work of all operations is an upper bound on the real work. A large challenge when performing an amortized analysis is guessing a good potential function, since this will result in a tighter upper bound on the real work. 10.1.2 Disjoint set The Lazy-Krukal algorithm explained in section 7.2.1.2 makes use of an MST. A disjoint set is used in building this MST. The fastest implementation of a disjoint set is the disjoint forest where each set is represented as a rooted tree and the
- 115. 10.1 Data structures103 root is the head of the set. This implementation does not provide efficient worst case bounds on all operations since the Find-Set operation can require linear work. However, in amortized sense the Find-Set operation is fast since it does some repair work which is prepaid by the Union operation. Two tricks which speed up the operations are used. The first trick is union by rank. The idea is that the smaller tree should be attached to the larger tree when performing Union. This is done to make the traversal from the leaf to the root in the Find- Set operation as short as possible. The rank of each node in the tree cannot be updated in constant time. However, the rank can be bound upwards, and this upper bound provides sufficient information to allow the amortized analysis to work. The second trick is path compression. Since the Find-Set operation has to visit each node on the path from from a start node to the root, then one could simply maintain the root pointers when visiting the nodes on the way to the root. The amortized analysis use a potential function which stores potential in the data structure according to the sum of rank for the whole forest. This means that potential is stored in the data structure when performing the Union operation, which can later be used to run from a node to the root and do path compression. The pseudocode and a rigorous proof for the time complexity can be found in [21] page 508. The analysis concludes that n disjoint set operations on a data structure containing m elements require amortized work equal to O(n · α(m)), where α(m) is the inverse Ackermann function. This function is constant for all practical purposes. 10.1.3 Priority Queue A priority queue is used in the construction algorithm to keep track of the unassigned jobs. The jobs in the priority queue are prioritized after a ”critical to assign” measure which describes how many technician plans a specific job can be assigned to. An important insight from the construction algorithm is, that each time a job is assigned to a technician plan all jobs in the feasibility list of that technician plan have to be updated since their critical value may have changed. This results in a lot of Update Key operations each time a single Extract Min operation is performed. The priority queue has been implemented by using a Splay tree since this data structure provides amortized O(lg(n)) running time for these two operations. A Splay tree is a binary search tree. Whereas most binary search trees, such as Red-Black trees and AVL trees, guarantee their performance by maintaining (almost) perfect balance, Splay trees guarantee their performance using amor-
- 116. 104 Implementation tization. Theidea is that operations are allowed to require much work only if they are balancing the search tree at the same time, and in this way making future operations faster. The balancing in splay trees are done by an operation called Splaying. A Splay operation consists of a sequence of double rotations. A double rotation involves three nodes and are performed to do a local balancing between these three nodes. This balancing results in the total height of the search tree being decreased by one in enough of these rotations for the amortized analysis to work. A sequence of rotations where one node is rotated all the way to the root is denoted a Splay. The potential function used in the amortized analysis is a function that sum up the size of each possible sub tree. Therefore a balanced tree will have less potential than an unbalanced one, and since splaying balances the tree a long search in the splay tree will be paid by the succeeding splay. A rigorous analysis of the time complexity and pseudocode for all the operations can be found in [19]. The analysis concludes that all operations on a Splay tree with n nodes require O(lg(n)) amortized work. A very nice property of the splay tree node is that recently touched nodes will be located near the root and will therefore be cached. This is a consequence of the Splay operation. Recall that the most time consuming part of the construction algorithm was the backtracking where nodes with low critical value were pushed back into the priority queue. It can be expected that the Splay tree will provide high efficiency in the construction algorithm since the Extract-Min operation will be fast when the element with low critical value is located near the top. Note that since each operation on a Splay tree with n elements has a time complexity of O(lg(n)), sorting m elements can by done by first adding each element and then extracting min m times. This will take O(m · lg(m)) time which is proven to be optimal for any comparison sorting algorithm1 . The splay tree is used for sorting in certain cases throughout the implementation. The Insert operation can be improved by using a lazy strategy. This improve- ment results in the operation only requiring constant amortized work. This improvement will however not improve the construction algorithm since a series of Update Key operations, which contains one Remove and one Insert, is always followed by a Extract Min which will make the lazyness indifferent. Another benefit of the Splay tree is that it is quite easy to implement. 1See [21] page 167.
- 117. 10.2 Extendability 105 10.2Extendability It was explained in section 1.1, how the software solution should be helpful to as many Dynamics AX customers as possible. Thus one of the main goals, when implementing the solver, was to make it as extendable as possible. The implemented solver is extendable in two ways: • It is possible to change all the soft constraints and some of the hard con- straints. • It is possible to extend the functionality of the solver by simply changing its arguments. Alternatives to a large set of the solver functionality are implemented, while it is quite easy to add new functionality to the solver. 10.2.1 Changing the objective function Changing the soft constraints can result in a decrease in solver performance. This can happen if new soft constraints change the objective value in a way that makes it harder to search the solution space. The four soft constraints from section 3.2.2 have all been implemented. New soft constraints can be implemented by specifying both a normal evaluation function as well as a delta evaluation function. The following code example shows how the mini- mize driving constraint is added. The DistanceTravelled class extends the SoftConstraintDescription class. Goal g = new Goal(); g.AddConstraint(new DistanceTravelled(), 1.0); 10.2.2 Changing the hard constraints Currently it is only possible to extend the hard constraints with a simple job to technician type of constraint. This choice has been made to maintain the effi- ciency of the bilities data structure. One could imagine hard constraints which, when adding a job j to a technician plan A, influenced technician plans differ- ent from A and jobs different from j. This could however make the bilities data structure far less effective, since it would have to perform checks on the bilities lists of those other jobs and technician plans. More on this in section 12.2.4. Hard constraints are created by implementing the HardConstraint interface.
- 118. 106 Implementation 10.3 Profiling Thissection will give an overview of how the solver makes use of the computa- tional power available. First a profiling of the time usage of the main components is made, and thereafter a more low level profiling is done to see which specific rutines in the code consumes the most computational effort. The profiling has been conducted using the following settings. • 4 tabu length resets in each Tabu search. • A c value of 200. c was the value determining when to stop the optimiza- tion. • A problem size of 800 jobs. Section 8.5 explained the flow of the solver, that is how it moves between opti- mizing, diversifying, merging and so on. Figure 10.1 shows how much time each of these components use of the total time. Figure 10.1: This pie chart shows how time is used by the solver. The solver has optimized over a period of 10 hours. Figure 10.2 gives an overview of how time is used between low level tasks. It is seen that operation on the bilities data structure takes half of the total time.
- 119. 10.4 Future work107 Figure 10.2: This pie chart shows how time is used between low level tasks. The solver has optimized over a period of 10 hours. 10.4 Future work Section 10.3 showed that delta evaluation only took up 30% of the total compu- tation time. The reason for this can either be that the delta evaluation is very fast, or that to much time is used on other parts of the solver. This section de- scribes a series of enhancements which could be implemented in case the latter is true. State copying State copying could be reduced by implementing a persistent data structure. A persistent version of the technician plans, the routes, the bilities data structure and the robustness shifts structure, i.e. the whole state, would have to be implemented. State copying in tabu search would be unnec- essary by making use of a persistent state. This is true since the most state copying takes place in this algorithm.
- 120. 108 Implementation Hash tablesHash tables are used alot throughout the code as the way of getting constant lookup without having to keep index integers around. To get rid of hashing overhead one could incapsulate an array in a hash table interface. Each element added would be required to ”hash” to a unique integer between 0 and n where n is the number of elements of this type. In this way one would not have to change the code base significantly and would still do without the index integers. This is feasible since the hash tables very often contain the set of technicians or the set of jobs, which are sets of constant size. Bilities data structure Profiling showed that around 50% of the computa- tion time was used on updating the bilities data structure. One could simply omit certain updates to the bilities structure. It would only be updates when a job is removed that could be omitted, since these omissions would remove solutions from the solutions space creating a prioritization between the size of the solution space and the running time of the solver. Omitting updates when a job were added would introduce illegal assignments. 10.5 Solver usage Creating a service technician schedule is a continuous process. Section 9.3 ex- plained how to deal with changed made to the problem definition. Figure 10.3 illustrates how these changes are fed back into the solver, when a schedule is desired. Figure 10.3: This figure illustrates how the solver is supposed to reuse old solutions to speed up the optimization. The address matrix is saved to a file to make the continuous updating of the schedule as fast as possible. On a n · n sized matrix one only has to perform n distance calculations when adding a new job or a new technician.
- 121. 10.6 Integration withDynamics AX 109 10.6 Integration with Dynamics AX The solver has been integrated in Dynamics AX through the use of a dynamic linked libary2 . This is possible since Dynamics AX has CLR interoperability meaning that .NET objects can by instantiated inside Dynamics AX using the X++ language3 . The X++ code integrating the solver dll with the Dynamics AX application can be found in appendix F. The user starts the solver by going through a small wizard. Figure 10.5 shows the steps necessary to set up the solver. Figure 10.4 shows how a dispatch board is used to visually show the assignment of service jobs in Dynamics AX. The dispatch board can therefore be used to show the result of a solver optimization. Figure 10.4: This dispatch board shows a schedule with three jobs. 2I.e. a .NET managed code .dll file. 3See [5] for more on the workings of Dynamics AX and the X++ language.
- 122. 110 Implementation Figure 10.5:This figure shows the five setup screens necessary to set up the solver.
- 123. Chapter 11 Solver tuning& practical testing The implemented solver will be tuned on test problems in section 11.2. Section 11.3 will test the solver on practical data. The solver components from chapter 8 are tuned to increase the general performance of the metaheuristic. The tuning will focus on creating a solver that performs well on any given input. Different concepts are going to be compared rather than focusing on tuning specific parameters. It is important to set up test problems which are similar to the real life problems when tuning the solver. A large part of section 11.2 will therefore deal with how to simulate test problems. A practical test will be performed by comparing a realized technician schedule with one created by the implemented and tuned solver. 11.1 Test machines The machines presented in table 11.1 have been used in both the tuning of the solver, as well as the practical test.
- 124. 112 Solver tuning& practical testing Machine # Processor (Each core) 1 Pentium M, 1.50 GHz 2 Pentium 4, 2.40 GHz 3 Pentium 4, 1.80 GHz 4 Pentium 4, 1.70 GHz 5 Pentium 4, 1.60 GHz 6 Pentium 4, 1.50 GHz 7 Pentium 4, 0.80 GHz Table 11.1: The machines used for tuning and sanity testing of the solver. Each test will specify the machine number corresponding to the test machine used in that test. The number of machines presented in table 11.1 might seem excessive. Recall that a very important parameter in order to make a meta- heurictic effective, is the ablility to investigate the different concepts. Testing the concepts has been a very time consuming task, so the number of test ma- chines has been a clear advantage. 11.2 Solver tuning The focus of this section is on increasing the performance of the four components described in chapter 8. Section 11.2.2 deals with the construction component, where the algorithms ability to find feasible solutions is investigated and tuned. The next section will focus on tuning the optimization component, that is mak- ing the tabu search heuristic as fast as possible while still achieving high value solutions. Section 11.2.4 will tune the diversification component making it as good as possible at finding new areas of the search space. The merge component will be investigated in section 11.2.5 to find the best merging concept. Finally the flow between these components will be tuned in section 11.2.6, i.e. when to apply diversification, merging etc. Large jobs were introduced in section 9.1. A construction heuristic taking the objective value into consideration were described in this section. Section 11.2.7 deals with the tuning of this part pf the solver.
- 125. 11.2 Solver tuning113 11.2.1 Setting up test problems This section will describe the test setup used in tuning the different parts of the metaheuristic. Instances of TRSP are characterized by a large set of variables, which have to be specified every time a test problem is created. An algorithm for specifiying this set of variables is presented. The idea is that the set of parameters given to the algorithm should be significantly smaller than the set of problem variables. 11.2.1.1 Problem size The size of the problems are specified by two parameters: • n which denotes the number of jobs. • ρ denoting the average number of jobs in each technician plan. The number of technicians m and the horizon in number of days h can be calculated using these two parameters. Equation 11.1 shows how the horizon is calculated. h = n ρ if n ρ < 30 30 else (11.1) Equation 11.2 shows how the number of technicians is calculated. m = n ρ · h (11.2) The idea is to keep the horizon less than a month, since this is a realistic optimization horizon. The number of technician plans p is equal to h · m. 11.2.1.2 Defining the WORKLOAD constraint The WORKLOAD constraint deals with job durations and transportation time. The average job duration can be computed as a function of n and p since the capacity of each technician plan is chosen to be a static value of eight hours. A parameter called b denoting the ratio between handling time and transportation time. If b equals 0.2, then the total handling time will equal 80% of the total
- 126. 114 Solver tuning& practical testing technician plan capacity. The duration of each job can be calculated in the following way: d = p n · (1 − b) (11.3) This is a simplified model since job durations are normally not the same in real life problems. Introducing variation on d is an attempt at meeting this fact. Variation can also be introduced on the capacity of the technician plans. A capacity of eight was chosen to simplify the problem generation. The job adresses and technician homebases can be generated by specifing a parameter τ. Each address is creating by assigning it a random point (x, y) from a 2τ · 2τ square. This approach makes it easy to maintain euclidean distances between the addresses by calculating them using Pythagoras equation. τ is chosen to be one hour in general. 11.2.1.3 Defining the ALLOWED constraint The ALLOWED constraint is a matrix A stating the allowed assignments. An assignment can either be disallowed because of a misfit in time or a misfit in skills. The technician plans were created such that a misfit in time is not possible, since jobs are allowed in the whole optimization horizon h. Creating a misfit in time is not important, since the case study showed that there are no correlation between job time frames and technician plans. The technician skills and job skills are however highly correlated as it was the case in the company interviews. Correlation between the technician skills and job skills are obtained by letting both technicians and jobs pick a a number of random skills from a pool of skills. This strategy creates correlation since the technician with the same skills are competing for the jobs requiring those skills. A parameter δ is used to define the amount of skills that each technician and job receive. The amount of skills is calculated in the following way: λ = n ρ (11.4) 11.2.1.4 Overview The difficulty of finding a feasible solution to a problem is a function of δ and b. b specifies how hard the WORKLOAD constraint is to satisfy, while δ specifies
- 127. 11.2 Solver tuning115 Symbol Explanations ρ Mean value of jobs in each technician plan. λ Number of skills. κ Number of repeats. τ Areasize. vd Variation in jobduration. δ How easy the ALLOWED constraint is to satisfy. b How easy the WORKLOAD constraint is to satisfy. Table 11.2: The introduced notation used for problem generation. how hard the ALLOWED constraint is to satisfy. Standard values for δ and b making the two constraints hard to satisfy are calculated a priori. In this way a test can simply state that it wants to have a hard WORKLOAD constraint or a hard ALLOWED constraint. The problems being generated are dependent on random numbers. A conse- quence of this is, that it is possible to generate different instances of the a problem setup by simply changing the seed in the random number sequence. The number of repeats of a specific problem setup is denoted κ. Table 11.2 provides an overview of the notation used when generating problems. 11.2.2 Construction This section will focus on the construction component. The test will focus on the components ability to solve hard problems. A hard problem is a problem where either the WORKLOAD constraint or the ALLOWED constraint is hard to satisfy. These two constraints are in this test characterized by two scenarios, the first one concerning the situation where a lot of driving is taking place, and the second situation where the skill matrix is sparse. 11.2.2.1 Workload This section will focus on how the construction heuristic can satisfy the WORK- LOAD constraint. Section 8.1 described a way of dealing with this constraint by minimizing transportation time. Two different concepts were suggested: • Apply Tabu search when the number of completely empty technician plans
- 128. 116 Solver tuning& practical testing κ n ρ τ δ b vd Test machine 10 {50,100,200,400,800} 4 60 easy infeasible 0.2 5 Table 11.3: Problem setup for the construction test concerning the WORK- LOAD constraint. are less than some threshold. • Apply Tabu search when a percentage of the technician plans are no longer empty. • Apply Tabu search when a certain percentage of the total time of all technician plans are used. This test will be performed by comparing different instances of each of the three strategies with a construction heuristic that does not minimize transportation time. The instances also include strategies where travel minimization is done more than once. Table 11.3 shows how the test problems were set up. Figure 11.1: The left graph illustrates solutions to problems of size n = 200. The right graph are on problems of size n = 800. The y-axis displays the average additional jobs assigned as compared to the one not performing transporta- tion time minimization. The x-axis displays the time used by the construction heuristics. The result of the test is shown in figure 11.1. It is seen that it is in general a beneficial idea to use Tabu search. On problems of size n = 200 it is seen that the two strategies based on empty plans are performing better than the one using a percentage of the total time. This conclusion is in constradiction with problems of size n = 800. One can therefore only conclude that the concept is beneficial, not recommend a specific algorithm.
- 129. 11.2 Solver tuning117 κ n ρ τ δ b vd Test machine 20 {50,100,200,400,800} 4 0 infeasible zero 0.2 2 Table 11.4: Problem setup for the construction test concerning the ALLOWED constraint. A property which seems to have significant impact on the quality is the time spent on minimizing the transportation time. The more time spent, the more jobs can be assigned by the construction heuristic. The computational effort of doing this optimization has to be compared to the number of additional jobs assigned by doing so. The time spent on the optimization is considered insignificant compared to the time used by the entire solver. The conclusion is to use many consecutive optimizations of transportation time. 11.2.2.2 Allowed This section will tune the construction heuristic to assign jobs to technicians when the A matrix is sparse, i.e. it is difficult to assign technicians with the nec- essary skills to the jobs. To ensure that the problems are only difficult because of the ALLOWED constraint, the problems are generated with transportation time set to zero. This is done to assure that the WORKLOAD constraint will not interfere with the tuning of backtracking. Two choices have to be made: • Should the backtracking be deterministic or random. • How many times should a job be allowed to be backtracked. This is referred to as the banning parameter, see section 8.1. The problems used in this test are defined in table 11.4. Figure 11.2 seems to indicate that for small values of the banning parameter, deterministic backtracking is better, and for larger values random backtracing is a better approach. It is seen that backtracking in general seems to be a good idea. This is the case although the effect of backtracking decrease when the backtracking gets sufficiently large. This decrease in effect seems to be dependent of the problem size, i.e. the smaller the problem is, the faster the effect will fade away.
- 130. 118 Solver tuning& practical testing Figure 11.2: These graphs show the number of additional jobs assigned as a function of the banning parameter for n=200 (left) and n=800 (right). Figure 11.3: These graphs show the runtime in minutes as function of the ban- ning parameter for n=200 (left) and n=800 (right). Another important aspect when deciding the value of the banning parameter, is the computational effort of the backtracking. Figure 11.3 shows the time con- sumption of backtracking. It was concluded in the WORKLOAD investigation, that time consumption of optimizing the tranportation time had little impact on total time of the entire metaheuristic. Figure 11.3 shows that this is not the case with backtracking. Therefore a time versus quality consideration is necessary. One can argue that for small problem instances, i.e n = 200, this is not the case, however for problems this small, the effect will terminate quite quickly. Therefore a constant banning parameter of 5 is chosen. It might seem unwise to stop the backtracking when further improvements prob- ably could be made by continuing. This is the case since all jobs must be assigned due to the n ASSIGNMENTS constraint. Any termination before all jobs are
- 131. 11.2 Solver tuning119 assigned would lead to infeasible solutions since the n ASSIGNMENTS is a hard constraint. There are several reasons for the suggested choice. First, if the problem really is infeasible, then the client would be better off with a good plan where some, hopefully many, jobs are assigned rather than no plan at all. Sec- ond, the described metaheuristic makes use of strategies such as diversification and merging. These require that new solutions are obtained from scratch which would not be possible if the construction heuristic is too time consuming. 11.2.3 Optimization Section 8.2 described general concecpts using in the implemented Tabu search heuristic. Important design choices were postponed to this section. A searies of alternatives were given for each concept. The aim of this section is investigate the different alternatives and choose the most appropriate ones for TRSP. The investigation will be done by construction of a number of different prob- lems and then letting a number of different Tabu search instances solve these problems. The best instance is going to be used in the following tests. Three different candidate lists are investigated: • Deterministic out/in which uses each technician plan after turn. Each technician plan is being used for two moves. First an out is performed and then an in is performed. • Random out/in which picks a technician plan and either performs an in or out. The choice is done at random weighted by the number of times each technician plan has been chosen. • Random more out which picks a technician plan and then performs either in or out. If out is chosen, four technician plans are chosen, and if in is chosen, only one technician plan is picked. Each choice is done with a random value, weighted by the number of times the technician plan has been chosen. Another undecided design choice is the tabu entity. Here two of the suggested tabu entities were implemented: • The inverse move is made tabu. • The job is made tabu.
- 132. 120 Solver tuning& practical testing κ n ρ τ δ b vd Test machine 5 {200,800} 4 60 easy easy 0.2 2 Table 11.5: Problem setup for the Tabu search test. A third crucial factor when designing a Tabu search metaheuristic is the length of the tabu list. Here three tabu list lengths are suggested: • A tabu list with a constant length of 10. • A tabu list with a length of √ n. • A tabu list with a lenth proportional with 1 2 · n. Even though it would be easier, from a computational point of view, to test each of the above three settings separately, this would not be a good idea. The reason for this is, that the settings interact. E.g. the less restrictive the tabu entity is, the longer one would expect the tabu list to be, and the different candidate lists would probably perform different with different tabu entities, since the deterministic candidate is assumed to search more locally than the random ones. The idea is therefore to investigate the performance of all combinations of the three. For each combination of the above mentioned settings, the same five problems were solved. These problems were generated with the specifications shown in table 11.5. The test results are shown in the graphs in figure 11.11 on page 136 and figure 11.12 on page 137. The graph shows the objective value as a function of time. Each test ran for eight minutes and all graphs have the same values on the axis’es. Each graph is a sum graph of the five problems. I.e. each time a graph steps up, it could be any of the five runs which has improved. The purpose with this test is to find the best performing candidate list, the best performing tabu entity and the corresponding best performing tabu length. First the analysis of the tabu entity will take place. It can be concluded from figure 11.11 that using job as the tabu entity seems to outperform move as tabu entity. Further, it can be concluded that a tabu list length of 1 2 ·n seems perform the best. The only thing left is to decide among the three suggested candidate list strategies. All of the three candidate lists seem to perform very well, with the deterministic strategy being a first among equals. In figure 11.12 on page 137, the n=800 case, it is seen that job as tabu entity is preferred. Since the problem here is larger, it might be possible that when
- 133. 11.2 Solver tuning121 using the length 1 2 ·n the time given to optimize in was to short, see e.g. the case where candidatelist is deterministic and the tabu entity is job. The first investigation was only conceptual, therefore further invistigation is done. Since the conceptual investigation was able to conclude the tabu entity and type of candidatelist, only the length is further investigated. Figure 11.4 and 11.5 illustrates this investigation. Figure 11.4: The objective values as function of time for different tabu lengths for n = 200. Each graph is a sum graph of five runs. It can be concluded that 1 2 ·n performs best for both n = 200 and n = 800. Most Tabu search literature suggests the use of a tabu list which is significant shorter than a 1 2 ·n. The two figures do however show that a linear tabu length is a good choice. An explanation of the very long tabu list can be found in the choice of candidate list. In each iteration all members of the candidate list are evaluated. The suggested choice of candidate list migth be large, so that each iteration is quite computationally demanding. The long tabu list will therefore speed up each iteration since it significantly shortens the candidate list, i.e. many elements
- 134. 122 Solver tuning& practical testing Figure 11.5: The objective values as function of time for different tabu lengths for n = 800. Each graph is a sum graph of five runs. which should have been in the candidate list are now declared tabu instead. A consequence of this is, that using aspiration critiria is worthless for TRSP since it would require evaluation of further solutions for each iteration. This can however not be concluded with certainty, since an aspiration criteria has not been implemented. A speed up approach which is widely used in the Tabu search literature, is to avoid the heavy computations in each iteration, by performing a neighbor move as soon as an improving move is found and thereby avoid evaluating the entire candidate list. However, this trick had no positive impact on TRSP. Apparently, the Tabu search makes many non-improving moves where the entire candidate list needs to be evaluated. One could argue that the design of the candidate list and tabu entity is unwise, since the investigation concluded that a very long tabu list should be used. Deriving a better choice for either one of these, is not trivial since the objective function is unknown for instances of TRSP.
- 135. 11.2 Solver tuning123 11.2.3.1 Determining the stopping criteria Even though Tabu search is able to escape a local optima it will probably fail, like all other local search algorithms, to investigate a very large part of the feasible search space. This section aims to investigate when Tabu search should stop improving on the objective value. This is done by applying the round count concept presented in chapter 8.2.6. The result of this investigation is shown in figure 11.6. There seems to be a trend that the implemented Tabu search can improve for a very long time. Even though the graph for n = 800 seems not to improve further, other tests have indicated that the implemented Tabu search will continue to improve as long as any test was ever run. This is a clear consequence of the choice of tabu list length. However, as the heuristic progresses, time spent between each improvement gets very long. Therefore, it could be an idea to use diversification at some point. This results in one having to stop Tabu search. By analyzing the graphs on figure 11.6 a round count of 800 is chosen. Figure 11.6: Illustrates the number of rounds needed when local search stops improving. The left graph shows the case where n = 200 and the right graph shows the case where n = 800. 11.2.4 Diversification The purpose of this test is to determine which of the two diversification concepts described in section 8.3 to use. Section 8.5 described how diversification is used in getting new solutions for the merging component. The goal of this test is
- 136. 124 Solver tuning& practical testing κ n ρ τ δ b vd Test machine 3 {200,800} 4 60 easy easy 0.2 4 Table 11.6: Problem setup for the diversification test. therefore to determine the diversification concept which is the best at getting both high-value and diversify solutions in a short amount of time. The test setup can be seen in table 11.6. Figure 11.7: Illustrates how the two diversification concepts perform on a prob- lem with 800 jobs. ”Pop all” removes all jobs from the solution, while ”Pop 20” remove 20 jobs. The removed jobs are banned in the subsequent optimization. Figure 11.7 illustrates the two diversification concepts used on a problem with 800 jobs. The two methods will be denoted ”pop-20” for the one removing 20 jobs, and ”pop-all” for the one removing all jobs. The graph shows how pop-20 generates 25% more solutions. It is however also seen how the objective value of these 10 solutions seem more or less the same, while pop-all generates 8 solutions with more diverse objective values. While this does not prove that the solutions are diverse, but only an indicator, Pop-all is chosen as the best diversification, since it is more important to get few diverse solutions compared to many equal solutions. As table 11.6 shows, this experiment was repeated three times for two different problem sizes. These experiments supported this argument.
- 137. 11.2 Solver tuning125 κ n ρ τ δ b vd Test machine 25 {200,800} 4 60 easy easy 0.2 2 Table 11.7: Problem setup for the merging test. 11.2.5 Solution merging Focus in this section will be on an investigation in which setup to choose when merging solutions. As desribed in section 8.4, solution merging is about identify- ing good parts of solutions and then merge these good parts together. Different ways of evaluating technician plans are proposed in section 8.4. Either one could focus on the relative value, the absolute value or one could combine these two. This will be part of the investigation in this section. When having chosen how to distinguish between technician plans, there is the question whether how many solutions should to be taken into account. Three and five solutions are merged. The setup of the problem is shown in table 11.7. Merging the solutions can be done in severel ways, in this investigation the following six different approaches will be investigated: • E 1 1 which tries to merge the solutions by choosing equally many tech- nician plans in each of the solutions. The value of the technician plans are the relative value plus the absolute value. • E 1 0 which tries to merge the solutions by choosing equally many tech- nician plans in each of the solutions. The value of the technician plans are only the relative value. • E 0 1 which tries to merge the solutions by choosing equally many tech- nician plans in each of the solutions. The value of the technician plans are only the absolute value. • B 1 1 which chooses the technician plans greedy from the solutions to be merged without considering where the technician plans originally came from. The value of the technician plans are the relative value plus the absolute value. • B 1 0 which chooses the technician plans greedy from the solutions to be merged without considering where the technician plans originally came from. The value of the technician plans are only the relative value.
- 138. 126 Solver tuning& practical testing • B 0 1 which chooses the technician plans greedy from the solutions to be merged without considering where the technician plans originally came from. The value of the technician plans are only the absolute value. The investigation consider two cases, n = 200 and n = 800. The results can be found in figure 11.8 and in figure 11.9. Figure 11.8: Merge test for n = 200. Figure 11.9: Merge test for n = 800. An analysis of figures 11.8 and 11.9 indicates that selection of good genes after their absolute values seems to be a better idea when the best overall technicain plans are selected to be merged. However, a deeper investigation af this setting reveals an undesirable property. This property is, that all technician plans used in the merger all originate, or allmost all of them, from the same solution which is the solution with the best objective value. A result of this is, that with these settings, the concept of merging does not work at all. Instead the solver simply does intensification of a single solution.
- 139. 11.2 Solver tuning127 The reason for intensification being a good idea can be explained by the long tabu list. Since the tabu list is a linear search, the search is very wide and not intense enough. The first important insight of this investigation is therefore that using intensification by banning technician plans with high objective values and then applying Tabu search on the remaining ones is crucial in order to obtain elite solutions. Analyzing the solution merger where relative values are used, results in more useful insights. If the technician plans were picked by the best overall value, one solution would in most cases completely dominate the other ones. This would again lead to intensification which was not the effect wanted. Further, the solu- tions obtained in this way, were not able to compete with the solution obtained by banning the technician plans with the best absolute value. The problem was that it was not necessarily the best solution that would be intensified since the relative values rely on the value of the solution provided by the construction heuristic. If the technician plan were ranked by relative values and picked equally from the solutions, it was concluded that the merge concept worked as it was intended to. Recall, that the relative values were developed with the purpose of allowing technician plans, that with large possibility, would be similar with a technician plan in the optimal solution, to be banned. Of course, the optimal solution to the problems which were investigated was not known. However, more than a handful of times it could be concluded, that the technician plans banned were the technician plans where jobs far away from the home base were located together. Using absolute ranking the technician plans with very little transportation time were considered attractive. This illustrates the basic difference between the relative measure and the absolute measure. This paragraph is a conclusion on the test. First and foremost the solutions obtained from Tabu search needs intensification which can be done by banning the technicain plans with best objective values. Second, the concept of merging were proven to work. The technician plans should be ranked by their relative values and three solutions should be merged by using the equal principle. 11.2.6 Solver flow The purpose of this section is to compare different flow concepts between the components described in chapter 8. Figure 11.10 shows the result of three different concepts used in solving a single problem. Each flow concept is used for five hours which results in a total run time of 15 hours. This is why only a single repetition is shown. The general test setup is shown in table 11.8.
- 140. 128 Solver tuning& practical testing κ n ρ τ δ b vd Test machine 1 {800} 4 60 easy easy 0.2 3 Table 11.8: Problem setup for the solver flow test. The three concepts tested were: • A single run using only the optimization component. • A flow switching between the optimization component and the diversifi- cation component. • A flow which starts off by creating a set of solutions. It then merges these solutions, while adding the resulting second generation solutions to the set as they are created. The merging always merge the best three solutions currently in the set using the round-robin strategy. Relative value is used to prioritize the solutions. The graph in figure 11.10 contains three important insights: • The optimization component finds a pretty good solution in a short amount of time. It has however a hard time finding improvements after this ini- tial phase. After about 320 it does however find an improvement, which indicates that the component will keep on improving if given more time. That is of course at a very slow rate. • Merging is clearly better than pure diversification, as seen after the intial face of creating solutions using diversification. The five optimizations after the initial face are all creating better solutions with merge as opposed to diversification. • The reason for choosing this kind of merge strategy was to illustrate the need for new ”blood”. The graph clearly shows how the merge strategy starts to create mediocre solutions after about 150 minutes. The reason for this is that it begins merging second generation solutions, which is a bad idea as explained in section 8.5.1. A second test has been conducted to support the conclusion that a merge and diversification strategy seems to work better than a pure optimization strategy. The two flow concepts were tested on 25 different problems where each concept had one hour to find a good solution. The merge concept found the best solution in every one of the 25 runs.
- 141. 11.2 Solver tuning129 Figure 11.10: All four soft constraints. κ n ρ τ δ b vd Test machine 1000 {100} 4 60 easy easy 0.2 4 Table 11.9: Problem setup for the addition of large jobs test. 11.2.7 Adding large jobs This section is an investigation of the large job extension. Two different strategies for adding large jobs to the solution were suggested in section 9.1.1. These were Best value selection and Largest difference selection. When designing a test to investigate the assignment of large jobs, one must also consider how the remaining jobs will be assigned afterwards since the final objective value also depends on these. Therefore the test setup is to first assign only the large jobs and calculate the objective value. This value is denoted the before value. Then the remaining jobs are assigned and Tabu search was used to optimize these. The value after the Tabu search is denoted the after value. Each Tabu search was run for 30 sec. The specific setup of the problems used for the large job assignments investiga- tion can be found in table 11.9. For both the before and after value for each repeat in the investigation a sign
- 142. 130 Solver tuning& practical testing Best value selection Largest difference selection Before After Before After Mean 1.33 -90.05 Mean -0.44 -91.30 # W 485 425 # W 244 323 # D 271 252 # D 271 252 # L 244 323 # L 485 425 Table 11.10: Investigation of the assignment of large jobs. #W is the number of times the heuristic has won, i.e. received the best objective value. #D stands for draw and #L stands for a loss. test is made, i.e. the heuristic with the best objective value was declared winner. The result of this investigation is shown in table 11.10. Analyzing table 11.10 the Best value selection performs best in mean and it wins significant more than the Largest difference selection. There seems to be a trend that the Largest difference selection performs better on the after value than on the before value. The Best value selection is however the best in general and will be chosen as the heuristic used in the final solver. 11.3 Practical test The performance of the implemented solver will be tested in this section. The most commonly used method in the operation research community for testing the performance of an metaheuristic is to compare it with problems having known near optimal solutions. In this way a solver can be tested directly against state of the art solvers, which results in a good indication of the performance of the solver. This approach will not be used in this thesis. This is the case because of the following two reasons: • TRSP is not a generally known problem, since it has been defined in this thesis. • It is not an aim to compare the implemented solver with state of the art solvers. The aim was to develop a sovler being able to compete with a human dispatcher, since potential clients are currently using human dispatching.
- 143. 11.3 Practical test131 11.3.1 The BioKube technician scheduling problem This section will describe a practical test of the solver. A real life technician schedule is compared to one created by the solver. A real life technician schedule has been obtained through a contact in the company BioKube1 . BioKube is a danish company manufacturing wastewater cleaners. The test has the following three goals: • Determine whether the TRSP model is able to encapsulate the problem of a company not included in the design face. • Determine whether the solver can compete with the human dispathing currently used in the company. • Test the performance of the soft constraint prioritization. BioKubes service technician problem is based on service agreements. A service agreement is made between BioKube and the client each time a wastewater cleaner is installed. This service agreement is required by law. The service agreement states that there must be no more than 1 year between each main- tenance check. BioKube has currently employed 4 service technicians to handle their maintenance. In 2007 BioKube performed 690 maintenance checks. Each of these jobs are scheduled to have a duration of 60 minutes. Each technician is capable of handling every service job. The four service technicians are also used in the production of the wastewater cleaners. The two schedules will be compared using three key performance indicators defined by BioKube. These are: • Days: Maximize time the technicians are in the production. This KPI is calculated in full days. • Drive: Minimize average driving per job. This KPI is calculated as trans- portation time in minutes per job. • Period: Maximize the period between the service checks for each sutomer. This KPI is calculated in days, as the average time between two service checks on the same plant. 1http://www.biokube.com/
- 144. 132 Solver tuning& practical testing 11.3.2 Service planning in BioKube today BioKube has one human dispatcher. She tries to optimize their plan using the stated KPIs. Since the dispatcher is only human, the performance indicators are prioritized to cope with them one at a time. The KPI with the highest priority is the smart driving performance indicator. Minimizing the driving this is done using the following approach. One of the service technicians is settled in Jutland in the city of Lang˚a. The human dispatcher assigns jobs to this technician by dividing Jutland into smaller areas. Each area is then visited approximately twice a year. When a certain area is visited the technician handles all the jobs in this area. This algorithm is repeated for each of the other technicians. This approach will very likely provide good schedules for the Drive and Days KPIs. However, it might not be very good for the Period KPI. BioKube has chosen the described approach since they think it will provide fairly good schedules and better schedules will require mulitobjective optimization which is considered to be hard for a human dispatcher. 11.3.3 Calculating the KPIs for BioKubes realized plan BioKubes 2007 plan contained the following data: • The locations of each job as well as the homebase of each technician. • The date at which each job were handled in 2007. • The date at which each job were handled in 2006. • The 2007 work calendar for each technician. Note that important data such as the specific lengths of the working days for each technician and which technician who handled each job could not be ob- tained. BioKube told that some of the technicians in periods within 2007 did some overtime work. Unfortunately, this was not recorded on specific dates. However, the dispatcher made schedules where each technician had a working day of maximum 7,5 hours per day. A consequence of this is that the overtime hours were not spent on handling service jobs.
- 145. 11.3 Practical test133 Key Performance Indicators Days Drive Period 579 100 258 Table 11.11: KPIs calculated for BioKubes 2007 plan. The solver was used to create a match between the jobs and the technicians. The ALLOWED constraint was used to ensure that the handling date of each job was correct. The solver was set to only consider driving. Unfortunately, no plan were found since the solver was not able to assign all jobs. An analysis of the data provided by BioKube revealed that some days had 30 jobs scheduled for a single technician. Recall, that the duration of each job was 60 minutes. These days were always on Fridays. Further it was noticed that no jobs were handled on the other four days of the week when the week contained a very busy Friday. The conclusion is therefore, that the data in their database is not necessarily 100 % correct. It is very likely that jobs handled through out the whole week were set as if they were handled Friday. The plan, for which the Biokube KPIs are calculated, are obtained by allowing jobs to be handled the entire week instead of a single day. When solving the problem, the solver was set to optimize both Days and Driving2 . The KPIs derived from the BioKube plan are shown in table 11.11. To the best of our knowledge the Biokube KPIs presented, are as close to the realized plan as possible. 11.3.4 Solving the BioKube TRSP In this section the BioKube TRSP of 2007 will be solved using the implemented solver. Before the solver can be used, some setup has to be made. First, the solver needs to know transportation times between each job and the technician homebases. These are calculated using Microsoft MapPoint. This is a quite time consuming task, since approximately 6902 2 transportation times have to be computed. The total computation time of these calls are approximately 27 hours. Note that these transportation times only need to be computed once. When these are computed, the transportation time matrix can be saved for later optimizations. If a new address is added one has to make 690 calculations using MapPoint. 2The exact set up is given in section 11.3.4.
- 146. 134 Solver tuning& practical testing The computation time of these calls are approximately five minutes, which is considered small enough for emergency planning3 . The KPIs need to be translated into soft constraints. The Drive and Period KPIs are not hard to translate into soft constraints. The minimize driving (DRI) and maximize job-to-time priority (JTT) are simply used. The Days KPI is more difficult. The idea is to use Robustness (ROB). Recall that robustness maximizes the number of standard jobs which can be added to a given plan. If the length of a standard job is set to 7,5 hours, which is the length of each of technicians workdays in BioKube, optimizing ROB will maximize the number of empty technician plans. This is equal to the number of days the technician can work producing the wastewater cleaners. The ROB soft constraint can be used with and without the square root. When ROB is used with the square root the optimization will spread the standard jobs in the shifts randomly. This is of no importance, which means that the ROB soft constraint can be used without the square root to simulate the Days KPI. The concept of an equalizer tool is introduced. The equalizer tool is used at prioritizing the soft constraints. This is done by changing the α values described in section 3.2.2.5. Table 11.12 shows how different equalizer settings can be used when solving the BioKube problem. Each equalizer setting has been optimized for five hours to make sure that the KPIs are comparable. In practice it should be adequate to simply change the equalizer setting and then run an optimization of a few minutes. A long optimization could be performed in the end to find a good solution. All tests have been run on test machine 2. The first three results in table 11.12 are shown to perform a sanity check of the equalizer. If one compares the KPIs and the associated α values, one can conclude that the equalizer works. When the DRI soft constraint has a high α value the Driving KPI has a good value and when the JJT has a high α value the Period KPI is good. Further, the Period and Driving seems to be negatively correlated.This is not surprising, since if jobs are being handled according to JTT it will require a lot of driving since only little synergy can be obtained. Recall, that the α coefficients were introduced to allow the user to make his prioritization between the soft constraints which is exactly what happens. The ROB soft constraint seems to be difficult to optimize. Even if the αROB has a very high value it only results in little impact on the Days KPI. An 3Note that an emergency call in many cases will be a known customer, i.e. the transporta- tion time is already a part of the transportation time matrix.
- 147. 11.3 Practical test135 Equalizer setting Key Performance Indicators No. ROB DRI JTT Days Drive Period 1 100% 0% 0% 593 148 335 2 0% 100% 0% 711 49 282 3 0% 0% 100% 542 164 338 4 50% 50% 0% 612 115 322 5 0% 50% 50% 554 144 345 6 33% 33% 33% 564 146 340 7 8% 90% 2% 609 87 339 8 1% 99% 0% 729 49 263 Table 11.12: Solutions to BioKube problem found by the solver. To the left the equalizer setting is shown and to the right the KPIs of the optimized solutions are shown. explanation to this can be found by investigating the geometry of the ROB soft constraint. The ROB soft constraint will have some sort of plateau, which results in a large amount of moves not changing the objective value and only few moves changing it a lot. This is of course as long a there are more than one job in a technician plan, and a single move will not result in an empty one. These low valued neighbor moves will therefore turn any search heuristic into random search. The optimization will however perform better, if the standard job is defined by a small duration compared to the capacity of a technician plan. Since the ROB soft constraint seems too hard to optimize alone, another very important insight can be seen from table 11.12. This insight is, that the DRI soft constraint seems to help ROB which is a very intuitive idea. When driving is done smart then the technicians will handle many jobs on few days. Further it is seen, that choosing a small value for αROB and a large value for αDRI will provide good solutions for the Days since this will eliminate the many plateaus. The KPIs found by the solver are compared to KPIs computed for BioKubes own solution. The solutions used in this comparison is with equalizer setting 2 and 7. It can be concluded that all of BioKubes KPIs are improved and the magnitude of the improvement is very significant. If equalizer setting 2 is chosen, the improvements are 23% for Days, 51% for Drive and 9% for Period. If equalizer setting 7 is used the improvements are 5% for Days, 16% for Drive and 31% for Period. The test therefore concludes that the solver can compete with a human dispatcher. Finally, some comments should be made about the schedules that are being compared. First, one can always criticize that a scheduled plan is compared
- 148. 136 Solver tuning& practical testing with a realized plan since the realized plan could have been changed when it was carried out. E.g. this case does not concern emergency calls. If a technician is out handling an emergency call he might also handle a maintenance check if it is located close by. Unfortunately, no data for the emergency calls could be obtained so emergency calls could not be taken into consideration. The improvements are however so significant that one could, with large certainty, conclude that this argument does not change the conclusion. Figure 11.11: This figure shows the investigation of different concepts of can- didatelists, different tabu entities and tabulengths within Tabu search where n = 200.
- 149. 11.3 Practical test137 Figure 11.12: This figure shows the investigation of different concepts of can- didatelists, different tabu entities and tabulengths within Tabu search where n = 800
- 150. 138 Solver tuning& practical testing
- 151. Chapter 12 Discussion The purposeof this section is twofold. The first part is a discussion of how the solver can be used in practice, while the second part deals with future improvements and extensions to the solver. The purpose of the first part is to clarify, how the solver can be used in offering the functionality, described in section 2.5. The scope of the project was presented in chapter 1. The limited scope of the project has resulted in a list of problems which have not been solved in this thesis. The second part of this section describes how these problems could be solved in the future. 12.1 Practical overview This section gives a high level overview of how the solver could be used in practice. Section 12.1.1 lists the problems which the solver is capable of solving when used in the right way. Section 12.1.2 discuss the extensions to Dynamics AX required for the solver to make use of its full potential.
- 152. 140 Discussion 12.1.1 Solvercapabilities This section will list the capabilities of the solver with reference to the desired functionality described in section 2.5. The section will also discuss solver per- formance, as well as include a discussion of how to handle periodic jobs. • Scheduling large jobs Section 9.1 describes how the solver deals with large jobs. Dealing with large jobs by assigning them up front will affect the solver performance as the number of large jobs increase. This was not seen as a problem, since having a small number of large jobs was an assumption. If this is not the case another heuristic should be considered. • Scheduling small jobs The focus of the suggested solver has been on scheduling the small jobs. It is proved for a single case and expected in general, that the solver can compete whith a human dispatcher is this discipline. • Emergency planning Emergency planning, or short term planning, hap- pens when small adjustments are made to the existing plan. Figure 10.3 on page 108 shows how reusing an existing solution speeds up optimization when changes are made. Since emergency jobs need to be included into the solution in a short amount of time, reusage of old solutions is time critical. Reuse of the address matrix, as desribed in section 10.5, is an approach to speed up emergency planning, since section 11.3 showed that creating an address matrix can be very time consuming. • Manual dispatching Section 9.4 described a way of providing the dis- patcher the possibility of forcing a specific assignment. This can be used to compensate for missing functionality in the implemented solver. Even though much of the desired functionality is already implemented in the presented solver, there do still exist cases being to specific for the this solver. • Realizeable schedules Realizable schedules are obtained by strictly ad- hering to the hard constraints presented in section 3.2.1. In the case where an infeasible problem is given to the solver, the result will be, that not all jobs will be scheduled. Only legal assignments are made, which means that all scheduled technician plans are realizable 12.1.1.1 Solver performance TRSP was defined in this thesis. This removes the possibility of comparing the performance of the implemented solver with the performance of other solvers.
- 153. 12.1 Practical overview141 The practical test in section 11.3 is an attempt at meeting this problem. The problem provided by BioKube could however be classified as easy. The problem is easy in the sense, that it could be solved by using only 204 technician plans out of 933 in total, see solution 8 in table 11.12 on page 135. Should the performance of the solver be tested satisfactorily, then harder problems with corresponding comparable solutions would be needed. 12.1.1.2 Periodic jobs One problem with the solver is periodic service, e.g. the time period between two service checks of a wastewater cleaner is not allowed to exceed one year. A specific usage of the solver is needed to be able to solve periodic service. The best way of avoiding this problem is, if possible, to use a planning horizon which equal to the time period of the jobs. Unfortunately this might not be possible, e.g. if there exists a overlap in the time periods of the jobs. The problem is here divided into two cases. • If the planning horizon is larger than the time periods, e.g. if the planning horizon is one year and the planning period is three months. This problem can be solved by only adding the first service job to the optimization and then use the solver every month. Each time a period job is handled, the next job can be added to the problem. Using this trick, one can avoid the time periods of the jobs which are what results in dependency between the jobs. Dependency between jobs are what the solver can’t deal with. • If the planning horizon is shorter than the time period, the solver will seek a solution where all jobs will be scheduled in the planning horizon due to the n ASSIGNMENT constraint. However such a solution might not exist due to the WORKLOAD constraint. This can be solved by only allowing the jobs, not scheduleable in the next planning horizon, to backtrack. I.e. if not all jobs are assigned, then the jobs which are allowed to use backtracking will very likely be the ones that are scheduled. For both the above cases one could argue, that such an approach would lead to results not being as good as possible, but the solver is already a metaheuristic providing non optimal solutions. It is still believed to be a fair conclusion; that the solver can provide functionality for scheduling of periodic service checks.
- 154. 142 Discussion 12.1.2 Solverintegration An important part of the problem definition in section 1.1 was that integration with Dynamics AX was essential. This has been achieved by providing a proof of concept integration between the solver and Dynamics AX. This section lists the extensions needed in Dynamics AX to create a fully functional prototype integration. Missing hard constraints To the best of our knowledge it is currently not possible to specify the ALLOWED constraint. It is possible to assign each technician a skill, but jobs cannot be assigned a required skill level. A job does contain a time window field, one can not change the value of this field. Manual dispatching The notion of red jobs were introduced in section 9.4. Red jobs provided the user with the option of doing manual dispatching. When applying manual dispathing, the system was supposed to treat these assignments as red jobs. This is not yet the case since jobs, in Dynamics AX, does not have knowledge about whether they are manually or automaticly assigned. Manual dispatching could be done using the dispatch board shown in figure 10.4 on page 109 while requiring Dynamics AX to mark jobs which were manually assigned. Unassigned jobs Dynamics AX does not currently have the notion of an unassigned job. Jobs are forced to be assigned to a specific technician at a specific time. Currently unassigned jobs are kept at their location prior to an optimization, giving the possibility of two jobs overlapping. 12.2 Future work This section discuss both algorithm improvements and model extensions which could be made if more time were available. 12.2.1 Tabu list length Section 11.2.3 concluded that the length of the tabu list should be linear in the number of jobs. This conclusion differs from the norm, since a constant or
- 155. 12.2 Future work143 quadratic function is generally suggested1 . The concept of a dynamic tabu list length was introduced in section 6.2.3.2. Implementation and investigation the efficiency of a dynamic tabu length is a candidate for future work. 12.2.2 Intensification In chapter 11 it was concluded that intensification by banning some technician plan were a very good idea. However, a very thorough investigation was not made. E.g. it was not concluded how many technician plans should be banned. Further, a dynamic banning strategy where more and more technician plans are banned seems fairly intuitive. This improvement is thought to the easiest of the proposed improvements. 12.2.3 Overnight stay Section 3.1 dealt with the model assumptions. One of the stated assumptions was that the service technicians should have a static starting address and end address. Introducing overnights in the model would result in dependency be- tween technician plans, i.e. an overnight stay would require the end address in one technician plan to be the same as the starting address in the successor plan. A preprocessing strategy is suggested instead. One could imagine a cluster ap- proach, where jobs located far away would be clustered into a single job. These jobs could then be handled as a large job. Clustering of a set of jobs would only be possible if every job could be handled by the same service technician and if they had a overlap in the time frames. If the model could handle overnight stays, it would make the solver able to create even better solutions since this assumption restraints the solution space. Allowing the service technicians to stay overnight could help some of the smaller companies cover larger service areas. An example of this is Endress + Hauser2 which were currently doing overnight stays in Jutland. E+H had only one service technician covering all of Jutland and therefore they sometime chose to let him stay overnight when working far away from home. 1See section 6.2.3.2. 2See section 2.1.
- 156. 144 Discussion 12.2.4 Tools Thecase study in section 2 made it quite clear that managing tools as part of the optimization would be a nice feature to have. The interviewed companies were interested in such a feature, since it could minimize the amount of equipment needed. The interviewed companies explained how they currently had to buy the same tools for all their service technicians. Introducing tool management would, just like in the case of overnight stays, create a dependency between technician plans. Assigning a technician A to a job j, where j requires a unique tool t, would make all assignments requiring tool t illegal while A was performing j. Two solutions for future investigation are proposed: • Let the technician plans take turn at getting the tools the associated tech- nician needs. The technician plan to tool assignment should be calculated a priori. How to perform the matchings would be a topic of further inves- tigation. • Update the bilities structure accordingly. When a job j requiring a tool t is assigned to a technician plan A, one could update the bilities data structure accordingly be removing the assignments which overlap with the timeframe of A and needs tool t. This could severely impact the performance of the bilities data structure. Even though two strategies are suggested here, it is considered unlikely that they will work in practice. The case interview with TDC revealed that their planning software had a price tag of 20 million DDK. This system was not capable of dealing with tools. Instead TDC has provided all of their technicians with all the tools they are skilled to handle. 12.2.5 Jobs without fullday time windows Previously it was assumed that, if a jobcould be assigned to a technician plan according to the ALLOWED constraint, then it could be handled in the entire time period of the technician plan. Unfortunately, this assumption made it impossible to require a job to be handled only in the for example the afternoon which is a strong request from e.g. some of TDC’s customers. The consequence of removing this assumption is, that instead of solving the classical TSP inside
- 157. 12.2 Future work145 each technician plan, a harder problem, namely the Traveling salesman with time windows (TSPTW), should be solved.
- 158.
- 159. Chapter 13 Conclusion The maincontribution in this thesis is a proof of concept software package being able to automate service technician planning. The requirements of such a planning tool have been identified through interviews with four companies. The interviews lead to the formulation of a problem denoted the Technician routing and scheduling problem (TRSP). TRSP were modeled as both a MIP and a CP model and commercial solvers were applied. It was concluded that neither of these solvers were able to solve instances corresponding to real-life problems. A metaheuristic was proposed since the commercial solvers were not able to solve the problem. The reason for proposing a metaheuristic as the solution were backed by TRSP being proven to be NP complete. The chosen metaheuristic was implemented in C# and integrated with Microsoft Dynamics AX 5.0. Tabu search was chosen as the basic optimization heuristic, while a semi-greedy construction heuristic was proposed as a way of getting feasible solutions. The construction heuristic was based on the ability to do randomized backtrack- ing. Tabu search features such as intensification and diversification were imple- mented, which were shown to result in a significant improvement. A heuristic inspired by evolutionary algorithms was implemented to deal with multiple ob- jectives. This approach was shown to improve the metaheuristic. The solver was tested and tuned using test problems based on data obtained
- 160. 148 Conclusion through thefour interviews. The solver performance was then tested by compar- ing it with a real technician schedule. This was done by obtaining real data from a fifth company. Solutions obtained by the solver were shown to improve all key performance indicators compared to those of the companys original schedule. We are proud to say that we were able to provide Microsoft with a proof of concept based on a metaheuristic being able to handle the stated requirements. The proof of concept provided in this thesis is a solver integrated with Dynamics AX 5.0 which is able to compete with human dispatching.
- 161. Appendix A Guide &API A.1 Quick guide This section contains a small guide in using the solver. The first example shows how to construct and solve a small problem with 1 technician and 1 job. Schedule schedule = new Schedule(); schedule.AddPeriod(new TimeFrame(60 * 9, 60 * 15)); Technician tech = new Technician("Peter", schedule, new Address("Jagtvej 69", "København N", "2200", "Denmark")); Technician[] techs = new Technician[] { tech }; JobDescription job = new JobDescription("Fix elevator", 60 * 2, new TimeFrame(0, 60 * 24), new Address("Strandboulevarden 100", "København Ø", "2100", "Denmark")); JobDescription[] jobs = new JobDescription[] { job }; TechnicianSkills skills = new TechnicianSkills(); skills.addSkill(tech, job); HardConstraint[] constraints = new HardConstraint[] { skills }; ProblemDescription problem = new ProblemDescription(techs, jobs, new Assignment[0], new TimeFrame(0, 60 * 24), constraints);
- 162. 150 Guide &API Dictionary<SoftConstraintDescription, double> objectives = new Dictionary<SoftConstraintDescription, double>(); objectives.Add(new DistanceTravelled(problem), 1.0); Goal softContainer = new Goal(objectives); Solver s = new Solver(); SolverSettings solverSettings = new SolverSettings(new TimeSpan(0, 0, 30)); SolutionDescription solDescription = s.GenerateSolution(softContainer, problem, solverSettings); A.2 API A.2.1 JobScheduling This namespace containts the main classes, which are needed to start solving technician planning problems. A.2.1.1 Solver The Solver class is the main class used to solve technician planning problems. The class is constructed by either using a constructor with no arguments re- sulting in a default solver, or by specifying a series of arguments resulting in a solver with custom parameters. public SolutionDescription GenerateSolution(Goal goal, ProblemDescription problemDesc, SolutionDescription oldSolution, SolverSettings settings) This method is used to start the actual solving of a problem. How this solving is done is specified in the Solver constructor. • Goal goal Tells the solver which goal function it should try and maximize. • ProblemDescription problemDesc Describes the problem, which is going to be solved. • SolutionDescription oldSolution If specified it gives the solver the possibility to use an old solution as starting point. This can improve the performance significantly.
- 163. A.2 API 151 •SolverSettings settings It is possible, through this argument, to spec- ify how the solver is going to act. An example is how much time it is going to use in solving the problem. The method is overloaded so that the caller doesn’t have to speficify the oldSolution argument. The Goal, ProblemDescription and SolutionDescription classes are documented in section A.2.2. SolverSettings in section A.2.1.2. A.2.1.2 SolverSettings The SolverSettings class is used to specify how the solver is going to solve a specific problem. Note: The properties in this class are not decided on yet. A.2.2 JobScheduling.Struct This namespace containts classes used in describing the problem at hand and the solution given back after the optimization is done. A.2.2.1 Address Describes an address by specifying a street name, a city and so on. A.2.2.2 Assignment An instance of the Assignment class specifies a specific job assigned to a specific technician at a specific time. It is used to describe a solution as well as red jobs. A.2.2.3 JobDescription The JobDescription class describes a job. A job has the following properties: • Description A textual description of the job. • Duration How much time the job takes to perform.
- 164. 152 Guide &API • Address Where the job is going to be performed. • Timeframe The period of time in which the job is allowed to be performed. A.2.2.4 ProblemDescription This class describes a problem. A ProblemDescription is constructed from the following arguments: • Technician[] techs An array of the technicians in the problem. • JobDescription[] greenJobs An array of the jobs, which are going to be performed by the technicians. • Assignment[] redJobs An array of jobs which are forced to be performed by a specific technician at a specific time. • HardConstraint[] hardConstraints The constraints which can’t be vi- olated. This could be technician skill levels.1 • Dictionary<Address, Dictionary<Address, int>> distanceMatrix A matrix with the distance in minutes between each address in the problem to each of the other addresses. If this argument isn’t specified then the class calls MapPoint and gets it to calculate the matrix. If there are a large number of jobs in the problem, then MapPoint might take a while to calculate this matrix, so it might be a good idea to calculate the matrix offline. A.2.2.5 Schedule A Schedule describes a technicians timeschedule. The schedule is by default totally empty. The class contains two methods: public void AddPeriod(TimeFrame period) Adds the timeperiod period to the schedule. 1See TechnicianSkills section A.2.4.2.
- 165. A.2 API 153 publicvoid AddPeriods(TimeFrame wholeperiod, int periodDuration, int startTime, int spaceBetweenPeriods) Adds a series of timeperiods with duration periodDuration starting from startTime, and with spaceBetweenPeriods specifing how much time there is going to be between the periods. wholeperiod specifies for how long the method should keep on adding periods. This method is useful if someone for example wants to add 9.00 to 15.00 every monday for two months. A.2.2.6 SolutionDescription This class describes a solution returned after running the solver on a problem. The class simply contains a list of Assignment’s. A.2.2.7 Technician The Technician class describes a technician in the problem. A technician has a name, a schedule and a homebase. A.2.2.8 TimeFrame This class is used to describe time periods in the problem. An example of its usage is in the Schedule class and in the JobDescription class. A.2.3 JobScheduling.SoftConstraints The JobScheduling.SoftConstraints namespace contains the softconstraints which a given problem can be optimized against. A.2.3.1 SoftConstraintDescription This is an abstract class from which it is possible to create softconstraints.
- 166. 154 Guide &API A.2.3.2 Goal The Goal class is a container for the soft constraints. The Goal class has a single constructor taking a Dictionary<SoftConstraintDescription, double> as argument. In this hashtable it is possible to assign a weight to each of the soft constraints. An example could be to make the distance travelled three times more important than the robustness of the plan. This could be done by giving distance travelled the key 3.0 in the hashtable, while giving robustness 1.0. A.2.3.3 DistanceTravelled This class is a soft constraint i.e. it extends the SoftConstraintDescription class. The idea behind the soft constraint is to minimize how much time the technicians use when travelling between jobs. The class only needs the problem description, when it is constructed. A.2.3.4 JobPriority The JobPriority class is a soft constraint. It can be used in the goal, if job to time priority is important. An example of the usage is if it is best that a specific job is scheduled on the 6/10-08 and worse the further it gets from that day. How important a job to time match is can be regulated, when constructing the class. The first argument of the constructor sets the priority that the job is scheduled at the specific time set in the second argument. A.2.3.5 TechPriority TechPriority is used to give a job-to-technician match a priority. The construc- tor takes one argument of the type Dictionary<Technician, Dictionary<JobDescription, double>>. The argument simply states that if a technician i is set to perform a job j then it gets the given value v. A.2.3.6 Robustness The purpose of the Robustness soft constraint is to make technician plans more robust. The constructor takes two arguments; the problem description and a
- 167. A.2 API 155 standardjob length. A.2.4 JobScheduling.HardConstraints This namespace containts everything related to the hard constraints. A.2.4.1 HardConstraint This is an abstract class describing a hard constraint. It can be extending if there is a need for new hard constraints. A.2.4.2 TechnicianSkills This class is a universal hard constraint, which isn’t constrainted to only han- dling skills. It is simply used to state whether it is allowed to let a specific technician perform a specific job.
- 168. 156 Guide &API
- 169. Appendix B Pseudocode This appendixcontains the pseudocode to the algotihms given in the thesis. B.1 Tabu search Input: Initial solution s Output: Improved solution s∗ s∗ = s; k = 1; while still time & stopping criteria not meet do Generate V ∈ N(s, k) ∈ N(s); Choose best s’ ∈ V; s = s’; if f(s∗ ) leq f(s) then s∗ = s end k = k + 1; end return s∗ ; Algorithm 1: Basic Tabu Search Algorithm
- 170. 158 Pseudocode B.2 2-opt Input:Initial tour t Output: Improved tour t while Changes were made do A = first node in t; A = A.next(); while A neq first node do B = A.Next(); foreach Neighbours n of B do C = n; D = C.Previous(); if |AB| + |CD| > |AD| + |BC| then forall Nodes m from A to C do temp = m.Next(); m.Next() = m.Previous(); m.Previous() = temp; end break; end end A.Next(); end end return t Algorithm 2: 2-Opt
- 171. B.3 AddToMST 159 B.3AddToMST Input: Set S, vertex x Output: Set Z, which are the nearpoints to x in S Z = ∅; V = S; while V is not empty do c = the vertex in V which is closest to x; Z = Z c; foreach vertex p in V do if dist(p,x) ≥ dist(p,c) then remove p from V; end end end return Z Algorithm 3: NearPoins Input: MST T, vertex x Output: MST T Z = NearPoints(Verticies in T, x); c = the vertex in Z closest to x; add edge {x,c} to T; Z = Z{c}; foreach vertex p in Z do e = longest edge in path from x to p; if dist(x,p) ≤ length(e) then delete egde e from T; add edge {x,p} to T; end end return T Algorithm 4: AddToMST
- 172.
- 173. B.4 Lazy-Kruskal 161 B.4Lazy-Kruskal Input: Graph G - G is an array containing the edges in a graph Output: MST T T = ∅; foreach vertex v in G do Make-Set(v); end push Lazy-QuickSort(G,1, length(G)) into Call-Stack while size(T) < (# of vertices in G -1 ) do e = pop Call-Stack; T = T e; Union(head(e),tail(e)); end return T Algorithm 5: Lazy-Kruskal Input: Array of edges G, position in G start, position in G end Output: smallest edge between position start and end in G while true do if start < end then smaller size, larger size = Partition(G,start,end); Push Lazy-QuickSort(G, end - larger size, end) into Call-Stack; Push Lazy-QuickSort(G, start, start + smaller size) into Call-Stack; end else if Find-Set(head(start) = Find-Set(tail(start)) then return G[start]; end pop Call-Stack; end Algorithm 6: Lazy-QuickSort Input: Array of edges G, position in G start , position in G end Output: smaller size, larger size pivot = G[random number between start and end] ; smaller size =0 ; larger size = 0 ; foreach j in G from start to (end - larger size) do if G[j] < pivot and Find-Set(head(j) = Find-Set(tail(j)) then swap in G(j, start + smaller size); smaller size = smaller size + 1; end else if G[j] ≥ pivot and Find-Set(head(j) = Find-Set(tail(j)) then swap in G(j, end - larger size); larger size = larger size + 1; j = j-1 ; end end return larger size, smaller size
- 174.
- 175. Appendix C Profiling Figure C.1:Tree-view of the low level profiling.
- 176.
- 177. Appendix D GAMS model ListingD.1: GAMS model 1 * <spmodel.gms > 2 * 3 $eolcom // 4 option iterlim =999999999; // avoid limit on iterations 5 option reslim =300; // timelimit for solver in sec. 6 option optcr =0.9; // gap tolerance 7 option solprint=OFF; // include solution print in .lst file 8 option limrow =100; // limit number of rows in .lst file 9 option limcol =100; // limit number of columns in .lst file 10 // -------------------------------------------------------------------- 11 12 Sets 13 i technicians / tech1 ,tech2 ,tech3 / 14 j jobs / job1 , job2 , job3 , job4 , job5 , hb / 15 t time / day1 , day2/ 16 j2(j) jobs but not hb / job1 , job2 , job3 , job4 , job5/ ; 17 18 Alias(j,k) ; 19 Alias(j2 ,k2): 20 21 Parameters 22 23 q(i,j,t) quality - skills - can tech i do job j at day t ; 24 q(’tech1 ’,’job1 ’,’day1 ’) = 1 ; 25 q(’tech1 ’,’job1 ’,’day2 ’) = 1; 26 q(’tech1 ’,’job2 ’,’day1 ’) = 1 ; 27 q(’tech1 ’,’job2 ’,’day2 ’) = 1 ; 28 q(’tech1 ’,’job3 ’,’day1 ’) = 1 ; 29 q(’tech1 ’,’job3 ’,’day2 ’) = 1 ; 30 q(’tech1 ’,’job4 ’,’day1 ’) = 1 ; 31 q(’tech1 ’,’job4 ’,’day2 ’) = 1 ; 32 q(’tech1 ’,’job5 ’,’day1 ’) = 1 ;
- 178. 166 GAMS model 33q(’tech1 ’,’job5 ’,’day2 ’) = 1; 34 q(’tech1 ’,’hb ’,’day1 ’) = 1; 35 q(’tech1 ’,’hb ’,’day2 ’) = 1; 36 q(’tech2 ’,’job1 ’,’day1 ’) = 1; 37 q(’tech2 ’,’job1 ’,’day2 ’) = 1; 38 q(’tech2 ’,’job2 ’,’day1 ’) = 1; 39 q(’tech2 ’,’job2 ’,’day2 ’) = 1; 40 q(’tech2 ’,’job3 ’,’day1 ’) = 1; 41 q(’tech2 ’,’job3 ’,’day2 ’) = 1; 42 q(’tech2 ’,’job4 ’,’day1 ’) = 1; 43 q(’tech2 ’,’job4 ’,’day2 ’) = 1; 44 q(’tech2 ’,’job5 ’,’day1 ’) = 1; 45 q(’tech2 ’,’job5 ’,’day2 ’) = 1; 46 q(’tech2 ’,’hb ’,’day1 ’) = 1; 47 q(’tech2 ’,’hb ’,’day2 ’) = 1; 48 q(’tech3 ’,’job1 ’,’day1 ’) = 1; 49 q(’tech3 ’,’job1 ’,’day2 ’) = 1; 50 q(’tech3 ’,’job2 ’,’day1 ’) = 1; 51 q(’tech3 ’,’job2 ’,’day2 ’) = 1; 52 q(’tech3 ’,’job3 ’,’day1 ’) = 1; 53 q(’tech3 ’,’job3 ’,’day2 ’) = 1; 54 q(’tech3 ’,’job4 ’,’day1 ’) = 1; 55 q(’tech3 ’,’job4 ’,’day2 ’) = 1; 56 q(’tech3 ’,’job5 ’,’day1 ’) = 1; 57 q(’tech3 ’,’job5 ’,’day2 ’) = 1; 58 q(’tech3 ’,’hb ’,’day1 ’) = 1; 59 q(’tech3 ’,’hb ’,’day2 ’) = 1; 60 61 parameter d(j) the duration of job j 62 / job1 180 63 job2 180 64 job3 180 65 job4 180 66 job5 180 67 hb 0 / ; 68 69 Table s(i,t) size - the amount of time tech i has on day t 70 day1 day2 71 tech1 480 480 72 tech2 480 480 73 tech3 480 480 ; 74 75 Table r(j,k) traveltime between job j and k 76 job1 job2 job3 job4 job5 hb 77 job1 0 30 30 30 30 30 78 job2 30 0 30 30 30 30 79 job3 30 30 0 30 30 30 80 job4 30 30 30 0 30 30 81 job5 30 30 30 30 0 30 82 hb 30 30 30 30 30 0 ; 83 84 Table p(i,j) preference value when job j is performed by tech i 85 job1 job2 job3 job4 job5 hb 86 tech1 1 2 1 1 2 0 87 tech2 3 2 1 3 2 0 88 tech3 1 1 3 1 1 0; 89 90 Table v(j,t) value for executing job j on day t 91 day1 day2 92 job1 6 8 93 job2 2 12 94 job3 4 4 95 job4 2 8 96 job5 10 6 97 hb 0 0 ;
- 179. 167 98 99 Scalar nnumber og jobs /6/ ; 100 101 102 binary Variables 103 x(i,j,t) does tech i do job j on day t 104 y(i,j,k,t) does tech i travel between job j and k on day ; 105 106 107 Positive Variable z(i,j,k,t) flow from j to k on tp ij ; 108 109 Variables obj the objective value; 110 111 Equations 112 cost objevtive function 113 myassign(j) all jobs must be assign to a tech 114 skills(i,j,t) only assign jobs arcording to q 115 techtime(i,t) each technician can only do work when he is working 116 driveto(i,k,t) aech job must de driven to if it is to be performed 117 drivenfrom(i,j,t) each job must be driven away from when is has been performed 118 flow(i,j,k,t) there can only be z-flow on a edge if it is y-choosen 119 sink(i,j2 ,t) the flow into each sink j2 is -1; 120 121 cost .. obj =e= sum(i,sum(j,sum(t, p(i,j)*x(i,j,t)))) + 122 sum(i,sum(j,sum(t, v(j,t)*x(i,j,t)))) - 123 sum(i,sum(j,sum(k,sum(t, r(j,k)*y(i,j,k,t))) )) 124 125 126 myassign(j2) .. sum(i, sum(t, x(i,j2 ,t))) =e= 1 ; 127 128 skills(i,j,t) .. x(i,j,t) =l= q(i,j,t) ; 129 130 techtime(i,t) .. sum(j, x(i,j,t)*d(j)) + sum(j,sum(k,r(j,k)*y(i,j,k,t))) =l = s(i,t); 131 132 driveto(i,k2 ,t) .. sum(j,y(i,j,k2 ,t)) =e= x(i,k2 ,t) ; 133 134 drivenfrom(i,j2 ,t) .. sum(k,y(i,j2 ,k,t)) =e= x(i,j2 ,t) ; 135 136 flow(i,j,k,t) .. z(i,j,k,t) =l= n * y(i,j,k,t); 137 138 sink(i,j2 ,t) .. sum(j,z(i,j,j2 ,t)) - sum(k,z(i,j2 ,k,t)) =e= x(i,j2 ,t); yes 139 140 141 Model spmodel /all/ ; 142 143 Solve spmodel using mip maximizing obj ; 144 145 DISPLAY x.l;
- 180.
- 181. Appendix E CP modelimplementation Listing E.1: CP model implementation using Optima 1 using System; 2 using System.Collections.Generic; 3 using System.Text; 4 using Microsoft.Planning.Solvers; 5 using System.IO; 6 7 namespace CPSolver 8 { 9 class Program 10 { 11 static void Main(string [] args) 12 { 13 SolveOurProblem (); 14 } 15 16 public static void SolveOurProblem () 17 { 18 FileInfo mainFile = new FileInfo(" CPSolverTest .txt"); 19 using ( StreamWriter sw = new StreamWriter (mainFile.OpenWrite ())) 20 { 21 Random r = new Random (2132); 22 23 int [] nArray = new int[] { 1, 2, 3, 4, 5, 6, 7 }; 24 int [] mArray = new int[] { 2, 3, 4, 5 }; 25 26 for (int a = 0; a < mArray.Length; a++) 27 { 28 for (int b = 0; b < nArray.Length; b++) 29 { 30 for (int c = 0; c < 5; c++) // Repeats 31 {
- 182. 170 CP modelimplementation 32 DateTime startTime = DateTime.Now; 33 34 int n = nArray[b]; // Number of jobs 35 int m = mArray[a]; // Number of TP ’s 36 37 int tp_size = 6*m + (int)((3 * n) / (double)m); // 200 38 39 int x_max = 4; 40 int y_max = 4; 41 42 double skills = 1; 43 int p_max = 4; // Max prioritet værdi 44 int t_max = 4; // Max skrue 45 46 int d_max = (int)Math.Sqrt(Math.Pow(x_max , 2) + Math.Pow(y_max , 2)); ; 47 48 int [][] jobPoint = new int[2 * m + n][]; 49 int [] homePoint = new int [2] { r.Next(x_max), r. Next(y_max) }; 50 51 { 52 for (int i = 0; i < jobPoint.Length; i++) 53 { 54 jobPoint[i] = new int [2]; 55 56 if (i < m || i >= m + n) 57 { 58 jobPoint[i][0] = homePoint [0]; 59 jobPoint[i][1] = homePoint [1]; 60 } 61 else 62 { 63 jobPoint[i][0] = r.Next(x_max); 64 jobPoint[i][1] = r.Next(y_max); 65 } 66 } 67 } 68 69 int [][] v_ij = new int[m][]; 70 { 71 for (int y = 0; y < v_ij.Length; y++) 72 { 73 v_ij[y] = new int[2 * m + n]; 74 } 75 76 for (int y = 0; y < v_ij.Length; y++) 77 { 78 for (int t = 0; t < v_ij[y]. Length; t++) 79 { 80 if (t < m || t >= m + n) 81 { 82 v_ij[y][t] = 1; 83 } 84 else 85 { 86 if (skills >= r.NextDouble ()) 87 { 88 v_ij[y][t] = 1; 89 } 90 else 91 { 92 v_ij[y][t] = 0; 93 }
- 183. 171 94 } 95 } 96} 97 } 98 99 int [][] d_jk = new int[2 * m + n][]; 100 { 101 for (int i = 0; i < d_jk.Length; i++) 102 { 103 d_jk[i] = new int[2 * m + n]; 104 } 105 106 for (int i = 0; i < d_jk.Length; i++) 107 { 108 for (int j = i; j < d_jk[i]. Length; j++) 109 { 110 int dist = (int)Math.Sqrt(Math.Pow( jobPoint[i][0] - jobPoint[j][0] , 2) + Math.Pow(jobPoint[i][1] - jobPoint[j][1] , 2)); 111 d_jk[i][j] = dist; 112 d_jk[j][i] = dist; 113 } 114 } 115 } 116 117 118 int [][] p_ji = new int[m][]; 119 120 for (int t = 0; t < p_ji.Length; t++) 121 { 122 p_ji[t] = new int[2 * m + n]; 123 124 for (int y = 0; y < p_ji[t]. Length; y++) 125 { 126 if (m <= y && y < m + n) 127 { 128 p_ji[t][y] = 1 + r.Next(p_max); // 1 or 2 129 } 130 } 131 } 132 133 int [] t_j = new int[2 * m + n]; 134 135 for (int t = 0; t < t_j.Length; t++) 136 { 137 if (m <= t && t < m + n) 138 { 139 t_j[t] = 1 + r.Next(t_max); // 0 or 1 140 } 141 } 142 143 FiniteSolver S = new IntegerSolver (null , null); 144 145 using (S) // This disposes S after use 146 { 147 ValueSet small_j = S. CreateInterval (1, m); 148 ValueSet large_j = S. CreateInterval (m + n + 1, 2 * m + n); 149 ValueSet middlelarge_j = S. CreateInterval (m + 1, 2 * m + n); 150 151 ValueSet i = S. CreateInterval (1, m);
- 184. 172 CP modelimplementation 152 ValueSet j = S. CreateInterval (1, 2 * m + n); // j is the jobs plus start and end for each tp 153 ValueSet time = S. CreateInterval (0, tp_size); // The time to use. 154 155 // Creating the 3 variables 156 Term [] R = S. CreateVariableVector (j, "R_", 2 * m + n); 157 Term [] Q = S. CreateVariableVector (time , "Q_", 2 * m + n); 158 Term [] Tau = S. CreateVariableVector (i, "Tau_" , 2 * m + n); 159 160 // Creating the 2 objective variables 161 Term [] goal1 = S. CreateVariableVector (S. CreateInterval (-d_max , 0), "goal1_", 2 * m + n); 162 Term [] goal2 = S. CreateVariableVector (S. CreateInterval (0, p_max), "goal2_", 2 * m + n); 163 164 165 // Creating the constraints 166 // 1 167 S. AddConstraints (S.Unequal(R)); 168 169 170 // 2 171 foreach (int t in small_j.Forward ()) 172 { 173 S. AddConstraints (S.Equal (0, Q[t - 1])); 174 } 175 176 // 3 177 foreach (int t in large_j.Forward ()) 178 { 179 S. AddConstraints (S.Equal(tp_size , Q[t - 1])); 180 } 181 182 // 4 183 foreach (int t in j.Forward ()) 184 { 185 foreach (int k in middlelarge_j .Forward () ) 186 { 187 S. AddConstraints (S.Implies(S.Equal(k, R[t - 1]), S. GreaterEqual (Q[k - 1], Q[t - 1] + d_jk[t - 1][k - 1] + t_j[k - 1]))); 188 } 189 } 190 191 // 5 192 foreach (int t in j.Forward ()) 193 { 194 foreach (int y in i.Forward ()) 195 { 196 if (v_ij[y - 1][t - 1] == 0) 197 { 198 S. AddConstraints (S.Unequal(y, Tau [t - 1])); 199 } 200 }
- 185. 173 201 } 202 203 //6 204 foreach (int t in small_j.Forward ()) 205 { 206 S. AddConstraints (S.Equal(t, Tau[t - 1])); 207 } 208 209 // 7 210 foreach (int t in large_j.Forward ()) 211 { 212 S. AddConstraints (S.Equal(t - (m + n), Tau [t - 1])); 213 } 214 215 // 8 216 foreach (int t in large_j.Forward ()) 217 { 218 S. AddConstraints (S.Equal(t - (m + n), R[t - 1])); 219 } 220 221 // 9 222 foreach (int t in j.Forward ()) 223 { 224 foreach (int k in j.Forward ()) 225 { 226 S. AddConstraints (S.Implies(S.Equal(k, R[t - 1]), S.Equal(Tau[k - 1], Tau[t - 1]))); 227 } 228 } 229 230 // The two objective constraints 231 232 233 foreach (int t in j.Forward ()) 234 { 235 foreach (int k in j.Forward ()) 236 { 237 S. AddConstraints (S.Implies(S.Equal(k, R[t - 1]), S.Equal(-d_jk[t - 1][k - 1], goal1[t - 1]))); // the objective is drive away from 238 } 239 } 240 241 foreach (int t in j.Forward ()) 242 { 243 foreach (int y in i.Forward ()) 244 { 245 246 S. AddConstraints (S.Implies(S.Equal(y, Tau[t - 1]), S.Equal(p_ji[y - 1][t - 1], goal2[t - 1]))); 247 } 248 } 249 250 251 Term [] goals = new Term[goal1.Length + goal2. Length ]; 252 goal1.CopyTo(goals , 0); 253 goal2.CopyTo(goals , goal1.Length); 254 255 // Creating the objective
- 186. 174 CP modelimplementation 256 S. TryAddMinimizationGoals (S.Neg(S.Sum(goals)) ); 257 258 Dictionary <Term , int > bestSoln = null; 259 foreach (Dictionary <Term , int > soln in S. EnumerateSolutions ()) 260 { 261 bestSoln = soln; 262 } 263 264 if (bestSoln == null) 265 { 266 Console.WriteLine("No solution found"); 267 } 268 /* else 269 { 270 PrintSol (R, Q, Tau , goal1 , goal2 , bestSoln ); 271 }*/ 272 273 // calculate obj value 274 int obj = 0; 275 int obj1 = 0; 276 int obj2 = 0; 277 278 279 for (int t = 0; t < 2 * m + n; t++) 280 { 281 obj1 += bestSoln[goal1[t]]; 282 obj2 += bestSoln[goal2[t]]; 283 } 284 obj = obj1 + obj2; 285 286 287 /* Console . WriteLine (" Obj1 :" + obj1); 288 Console . WriteLine (" Obj2 :" + obj2); 289 Console . WriteLine (" Obj :" + obj); 290 291 Console . WriteLine (" Done ");*/ 292 } 293 294 TimeSpan timeUsed = DateTime.Now - startTime; 295 296 Console.WriteLine("n: " + n + " m: " + m + " time : " + timeUsed. TotalSeconds ); 297 298 sw.WriteLine(n + ";" + m + ";" + timeUsed. TotalMilliseconds ); 299 sw.Flush (); 300 } 301 } 302 } 303 } 304 } 305 306 private static void PrintSol(Term [] R, Term [] Q, Term [] Tau , Term [] goal1 , Term [] goal2 , Dictionary <Term , int > soln) 307 { 308 Console.WriteLine("TAU:"); 309 for (int tau = 0; tau < Tau.Length; tau ++) 310 { 311 Console.WriteLine(tau +1 + ": " + soln[Tau[tau ]]); 312 } 313 314 Console.WriteLine("R:");
- 187. 175 315 for (inth = 0; h < R.Length; h++) 316 { 317 Console.WriteLine(h+1 + ": " + soln[R[h]]); 318 } 319 320 Console.WriteLine("Q:"); 321 for (int h = 0; h < Q.Length; h++) 322 { 323 Console.WriteLine(h + 1 + ": " + soln[Q[h]]); 324 } 325 326 Console.WriteLine("Cost1:"); 327 for (int h = 0; h < goal1.Length; h++) 328 { 329 Console.WriteLine(h + 1 + ": " + soln[goal1[h]]); 330 } 331 332 Console.WriteLine("Cost2:"); 333 for (int h = 0; h < goal2.Length; h++) 334 { 335 Console.WriteLine(h + 1 + ": " + soln[goal2[h]]); 336 } 337 } 338 } 339 }
- 188. 176 CP modelimplementation
- 189. Appendix F Dynamics AXintegration Listing F.1: X++ class ServiceOptimize 1 public class ServiceOptimize 2 { 3 JobScheduling .Struct.TimeFrame wholeperiod; 4 utcdatetime starttime; 5 6 public void new( utcdatetime _starttime , utcdatetime _endtime ) 7 { 8 starttime = _starttime; 9 wholeperiod = new JobScheduling .Struct.TimeFrame (0, this. convertTime(_endtime)); 10 } 11 12 JobScheduling .Struct. SolutionDescription optimize( JobScheduling . SoftConstraints .Goal goal , JobScheduling .Struct. ProblemDescription probDesc , int timeInSec) 13 { 14 JobScheduling .Struct. SolutionDescription solution; 15 JobScheduling .Solver solver = new JobScheduling .Solver (); 16 JobScheduling . SolverSettings settings = new JobScheduling . SolverSettings (new System.TimeSpan (0, 0, timeInSec)); 17 18 solution = solver. GenerateSolution (goal , probDesc , settings); 19 return solution; 20 } 21 22 void updateDatabase ( JobScheduling .Struct. SolutionDescription solDesc) 23 { 24 int length; 25 JobScheduling .Struct.Assignment [] assigns; 26 int i; 27 JobScheduling .Struct.Assignment assignment;
- 190. 178 Dynamics AXintegration 28 JobScheduling .Struct. JobDescription job; 29 JobScheduling .Struct.Technician tech; 30 int time; 31 str jobDesc; 32 boolean b; 33 str techName; 34 utcdatetime timeFrom; 35 utcdatetime timeTo; 36 int duration; 37 38 smmActivities activities; 39 smmActivityParentLinkTable linkTable; 40 41 ttsbegin; 42 while select forupdate activities join linkTable 43 where activities. ActivityNumber == linkTable. ActivityNumber && 44 linkTable.RefTableId == tablenum( SMAServiceOrderLine ) 45 { 46 assigns = solDesc. get_AssignmentArray (); 47 length = assigns.get_Length (); 48 49 b = false; 50 for (i = 0; i < length; i++) 51 { 52 assignment = assigns.GetValue(i); 53 job = assignment.get_Job (); 54 jobDesc = job. get_Description (); 55 if (jobDesc == activities. ActivityNumber ) 56 { 57 tech = assignment. get_Technician (); 58 time = assignment.get_Time (); 59 techName = tech.get_Name (); 60 b = true; 61 break; 62 } 63 } 64 65 if (!b) 66 { 67 // Do nothing 68 } 69 else 70 { 71 duration = job. get_Duration (); 72 timeFrom = DateTimeUtil :: addMinutes(starttime , time); 73 timeTo = DateTimeUtil :: addMinutes(starttime , duration + time); 74 75 activities. ResponsibleEmployee = techName; 76 activities. StartDateTime = timeFrom; 77 activities.EndDateTime = timeTo; 78 activities.update (); 79 } 80 } 81 ttscommit; 82 } 83 84 JobScheduling .Struct. ProblemDescription createProblemDescription () 85 { 86 JobScheduling .Struct.Technician [] techs; 87 JobScheduling .Struct. JobDescription [] greenJobs; 88 JobScheduling .Struct.Assignment [] redJobs;
- 191. 179 89 JobScheduling .HardConstraints . HardConstraint [] hardConstraints ; 90 JobScheduling .Struct.TimeFrame period; 91 JobScheduling .Struct. ProblemDescription probDesc; 92 JobScheduling .Struct. AddressMatrix matrix; 93 System.IO.FileInfo addrFile; 94 int i; 95 int length; 96 str name; 97 JobScheduling .Struct. JobDescription jobDesc; 98 JobScheduling .Struct.Technician technician; 99 ; 100 101 addrFile = new System.IO.FileInfo("C: addrMatrix.txt"); 102 /* 103 * Getting the data from the database . 104 */ 105 techs = this. findTechnicians (); 106 this. findCalendars (techs); 107 greenJobs = this.findJobs (); 108 redJobs = new JobScheduling .Struct.Assignment [0](); // No red jobs. 109 hardConstraints = new JobScheduling . HardConstraints . HardConstraint [0](); // No extra hard constraints . 110 111 print "Loading the address matrix"; 112 /* 113 * Creating the address matrix . 114 */ 115 matrix = JobScheduling . AddressMatrixLoader :: Load(addrFile); 116 matrix = new JobScheduling .Struct. AddressMatrix (techs , greenJobs , redJobs , matrix); 117 JobScheduling . AddressMatrixLoader :: Save(addrFile , matrix); 118 119 print "Finished loading the address matrix"; 120 /* 121 * Finally creating the problem description ... 122 */ 123 probDesc = new JobScheduling .Struct. ProblemDescription (techs , greenJobs , redJobs , wholeperiod , hardConstraints , matrix); 124 125 return probDesc; 126 } 127 128 JobScheduling .Struct.Technician [] findTechnicians () 129 { 130 Array techs = new Array(Types :: Class); 131 JobScheduling .Struct.Technician [] toBeReturned ; 132 JobScheduling .Struct.Technician tech; 133 JobScheduling .Struct.Address techAddress ; 134 135 int i = 1; 136 int returnLength ; 137 138 /* 139 * Tables 140 */ 141 EmplTable emplTable; 142 DirPartyAddressRelationship dirPartyAddressRelationship ; 143 DirPartyAddressRelationshipMapping dirPartyAddressRelationshipMapping ; 144 Address address; 145 ;
- 192. 180 Dynamics AXintegration 146 147 while select emplTable join DirPartyAddressRelationship join DirPartyAddressRelationshipMapping join Address 148 where emplTable. DispatchTeamId != ’’ && 149 DirPartyAddressRelationshipMapping . RefCompanyId == Address.dataAreaId && 150 DirPartyAddressRelationshipMapping . AddressRecId == Address.RecId && 151 DirPartyAddressRelationshipMapping . PartyAddressRelationshipRecId == DirPartyAddressRelationship .RecId && 152 EmplTable.PartyId == DirPartyAddressRelationship .PartyId 153 { 154 // info( strfmt ("%1 , %2", emplTable .EmplId , Address . Address )); 155 156 techAddress = new JobScheduling .Struct.Address( Address.Street , Address.City , Address.ZipCode , Address. CountryRegionId ); 157 tech = new JobScheduling .Struct.Technician(emplTable. EmplId , new JobScheduling .Struct.Schedule (), techAddress); 158 159 techs.value(i, tech); 160 161 i++; 162 } 163 164 print "#techs found:"; 165 print i-1; 166 167 toBeReturned = new JobScheduling .Struct.Technician[i -1](); 168 returnLength = toBeReturned .get_Length (); 169 170 for (i = 0; i < returnLength ; i++) 171 { 172 toBeReturned .SetValue(techs.value(i+1), i); 173 } 174 175 return toBeReturned ; 176 } 177 178 JobScheduling .Struct. JobDescription [] findJobs () 179 { 180 int duration; 181 JobScheduling .Struct.Address address; 182 JobScheduling .Struct. JobDescription job; 183 184 JobScheduling .Struct. JobDescription [] toBeReturned ; 185 Array jobs = new Array(Types :: Class); 186 int i = 1; 187 int returnLength ; 188 189 /* 190 * Tables 191 */ 192 EmplTable emplTable; 193 smmActivities activities; 194 smmActivityParentLinkTable linkTable; 195 SMAServiceOrderLine serviceLine; 196 SMAServiceOrderTable serviceOrder ; 197 ;
- 193. 181 198 199 while selectemplTable join activities join linkTable join serviceLine join serviceOrder 200 where emplTable. DispatchTeamId != ’’ && empltable. CalendarId != ’’ && 201 activities. ResponsibleEmployee == emplTable .EmplId && 202 activities. ActivityNumber == linkTable. ActivityNumber && 203 linkTable.RefTableId == tablenum( SMAServiceOrderLine ) && 204 serviceLine.ActivityId == activities. ActivityNumber && 205 serviceLine. ServiceOrderId == serviceOrder . ServiceOrderId 206 207 { 208 // info( strfmt ("%1 %2 %3 %4", activities . ActivityNumber , activities . StartDateTime , activities . EndDateTime , serviceOrder . ServiceAddress )); 209 210 duration = this.convertTime(activities.EndDateTime) - this. convertTime (activities. StartDateTime ); 211 address = new JobScheduling .Struct.Address( serviceOrder .ServiceAddressStreet , serviceOrder . ServiceAddressCity , serviceOrder . ServiceAddressZipCode , serviceOrder . ServiceAddressCountryRegion ); 212 job = new JobScheduling .Struct. JobDescription ( activities.ActivityNumber , duration , wholeperiod , address); 213 214 jobs.value(i, job); 215 i++; 216 } 217 218 print "#jobs found:"; 219 print i-1; 220 221 toBeReturned = new JobScheduling .Struct. JobDescription [i -1]() ; 222 returnLength = toBeReturned .get_Length (); 223 for (i = 0; i < returnLength ; i++) 224 { 225 toBeReturned .SetValue(jobs.value(i+1) , i); 226 } 227 228 return toBeReturned ; 229 } 230 231 void findCalendars ( JobScheduling .Struct.Technician [] techs) 232 { 233 JobScheduling .Struct.Schedule s; 234 JobScheduling .Struct.Technician t; 235 236 utcdatetime timeFrom; 237 utcdatetime timeTo; 238 int fromInt; 239 int toInt; 240 241 int length; 242 int indx; 243 str techName; 244 JobScheduling .Struct.TimeFrame techFrame;
- 194. 182 Dynamics AXintegration 245 246 /* 247 * Tables 248 */ 249 EmplTable emplTable; 250 WorkCalendarDate workCalendarDate ; 251 WorkCalendarDateLine workCalendarDateLine ; 252 ; 253 254 while select emplTable join workCalendarDate join workCalendarDateLine 255 where emplTable. DispatchTeamId != ’’ && empltable. CalendarId != ’’ && 256 workCalendarDate .CalendarId == emplTable. CalendarId && 257 workCalendarDateLine .CalendarId == workCalendarDate .CalendarId && 258 workCalendarDateLine .TransDate == workCalendarDate .TransDate 259 260 { 261 // info( strfmt ("%1 %2 %3 %4", emplTable .EmplId , workCalendarDate .TransDate , workCalendarDateLine .FromTime , workCalendarDateLine . ToTime )); 262 263 timeFrom = DateTimeUtil :: newDateTime( workCalendarDate .TransDate , workCalendarDateLine .FromTime); 264 timeTo = DateTimeUtil :: newDateTime( workCalendarDate . TransDate , workCalendarDateLine .ToTime); 265 266 fromInt = this.convertTime(timeFrom); 267 toInt = this.convertTime(timeTo); 268 269 length = wholeperiod.get_To (); 270 if (fromInt < length && toInt > 0) 271 { 272 if ( fromInt < 0 ) 273 { 274 fromInt = 0; 275 } 276 277 278 if ( toInt > length ) 279 { 280 toInt = length; 281 } 282 283 if (fromInt != toInt) 284 { 285 length = techs.get_Length (); 286 287 for (indx = 0; indx < length; indx ++) 288 { 289 t = techs.GetValue(indx); 290 291 techName = t.get_Name (); 292 if (techName == emplTable. EmplId) 293 { 294 techFrame = new JobScheduling . Struct.TimeFrame (fromInt , toInt) ; 295 s = t. get_Schedule ();
- 195. 183 296 s.AddPeriod(techFrame ); 297 break; 298} 299 } 300 } 301 } 302 } 303 } 304 305 int convertTime( utcdatetime dtime) 306 { 307 int64 diff = DateTimeUtil :: getDifference (dtime , starttime); 308 309 int diffInMinutes = diff / 60; 310 311 return diffInMinutes ; 312 } 313 } Listing F.2: Method called by the the wizard when pressing finish 1 public void closeOk () 2 { 3 JobScheduling .Struct. SolutionDescription solDesc; 4 JobScheduling .Struct. ProblemDescription probDesc; 5 JobScheduling . SoftConstraints .Goal goal; 6 int i; 7 int length; 8 JobScheduling .Struct.Assignment [] assArray; 9 JobScheduling .Struct.Assignment assign; 10 JobScheduling .Struct. JobDescription jobDesc; 11 ServiceOptimize serviceOptimizer ; 12 utcdatetime fromTime; 13 utcdatetime toTime; 14 ; 15 16 super (); 17 18 // utcdatetime format : 2008 -01 -29 T13 :38:47 19 fromTime = fromDateTime . dateTimeValue (); 20 toTime = toDateTime. dateTimeValue (); 21 22 serviceOptimizer = new ServiceOptimize (fromTime , toTime); 23 24 print "Starting the creation of the problem description "; 25 probDesc = serviceOptimizer . createProblemDescription (); 26 print "The creation of the problem description ended"; 27 28 goal = new JobScheduling . SoftConstraints .Goal (); 29 goal. AddConstraint (new JobScheduling . SoftConstraints . DistanceTravelled ( probDesc), travelField .realValue ()); 30 goal. AddConstraint (new JobScheduling . SoftConstraints .Robustness(probDesc , 120) , robustField.realValue ()); 31 print "Starting the optimization "; 32 solDesc = serviceOptimizer .optimize(goal , probDesc , optiTime.value ()); 33 print " Optimization ended"; 34 35 info(solDesc. GetLongString ()); 36 37 print "Updating the database"; 38 serviceOptimizer . updateDatabase (solDesc); 39 }
- 196. 184 Dynamics AXintegration
- 197. Bibliography [1] Combinatorics, Algorithms,Probabilistic and Experimental Methodologies, chapter The Tight Bound of First Fit Decreasing Bin-Packing Algorithm Is FFD(I)≤11/9·OPT(I)+6/9. Springer Berlin / Heidelberg, 2007. [2] Le Pape Claude Nuijten Wim Baptiste, Philippe. Constraint-Based Scheduling Applying Constraint Programming to Scheduling Problems. Kluwer Academic Publishers, London, 2001. [3] Filippo Focacci, Andrea Lodi, and Michela Milano. A hybrid exact algo- rithm for the tsptw. INFORMS J. on Computing, 14(4):403–417, 2002. http://dx.doi.org/10.1287/ijoc.14.4.403.2827. [4] Robert Ghanea-Hercock. Applied Evolutionary Algorithms in Java. Black- well Scientific Publications, New York, New York, 2003. [5] Olsen et al Greef, Pontoppidan. Inside Microsoft Dynamics AX 4.0. Mi- crosoft Press, Redmond, Washington, 2006. [6] John E. Hopcroft, Rajeev Motwani, Rotwani, and Jeffrey D. Ullman. In- troduction to Automata Theory, Languages and Computability. Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. [7] M. R. Garey & D. S. Johnson. COMPUTERS AND INTRACTABILITY - A Guide to the Theory of NP-Completeness. Murray Hill, San Francisco, California, 1979. [8] R. A. Johnson. Miller & Freund´s Probability and Statistics for Engineers. Prentice-Hall, London, 2000.
- 198. 186 BIBLIOGRAPHY [9] P.J. Stuckey K. Marriott. Programming with Constraints - An Introduction. The MIT Press, Cambridge, Massachusetts, 2001. [10] E. K. Burke & G. Kendall. SEARCH METHODOLOGIES - Introductory Tutorials in Optimization and Decision Support Techniques. Springer, New York, New York, 2005. [11] F. Glover & M. Laguna. TABU SEARCH. Kluwer Academic Publishers, Norwell, Massachusetts, 1997. [12] E. H. L. Aarts & J. K. Lenstra. Local Search in Combinatorial Optimization. Princeton University Press, London, 1997. [13] G. Lueker. manuscript. Princeton University, 1976. [14] Irvin J. Lustig and Jean-Fran¸cois Puget. Program does not equal program: Constraint programming and its relationship to mathematical program- ming. Interfaces, 31(6):29–53, 2001. http://dx.doi.org/10.1287/inte. 31.7.29.9647. [15] C. Nilsson. Heuristics for the traveling salesman problem. http://www. ida.liu.se/~TDDB19/reports_2003/htsp.pdf. [16] C. R. Reeves. Modern Heuristic Techniques for Combinatorial Problems. Blackwell Scientific Publications, London, 1993. [17] MAURICIO G.C. RESENDE. Greedy randomized adaptive search pro- cedures (grasp). AT&T Labs Research Technical Report, 2001. http: //www.research.att.com/~mgcr/doc/sgrasp.pdf. [18] Stephan Scheuerer. A tabu search heuristic for the truck and trailer routing problem. Comput. Oper. Res., 2006. http://dx.doi.org/10.1016/j.cor. 2004.08.002. [19] Robert E. Sleator, Daniel D. & Tarjan. Self-adjusting binary search trees. Journal of the Association for Computing Machinery, 1985. http://www. cs.cmu.edu/~sleator/papers/self-adjusting.pdf. [20] Mike Soss. Online construction of a minimal spanning tree (mst). http: //cgm.cs.mcgill.ca/~soss/geometry/online_mst.html, 1997. [21] R. L. Rivest & C. Stein T. H. Cormen, C. E. Leisersoon. Introduction to Algorithms. The MIT Press, Cambridge, Massachusetts, 2001. [22] J.P. Rasson V. Granville, K. Krivanek. Simulated annealing: A proff of convergence. PATTERN ANALYSIS AND MACHINE INTELLIGENCE, 1994, (vol. 16, No. 6) pp. 652-656. http://doi.ieeecomputersociety. org/10.1109/34.295910.
- 199. BIBLIOGRAPHY 187 [23] DavidH. Wolpert and William G. Macready. No free lunch theorems for search. Technical Report SFI-TR-95-02-010, Santa Fe, NM, 1995. citeseer.ist.psu.edu/wolpert95no.html.
- 200.
- 201. BIBLIOGRAPHY 189 [11] [10][5] [7] [21] [6] [12] [16] [4] [8] [2] [9] [19] [15] [17] [18] [22] [14] [13] [3] [23] [1] [20]