Het inplannen van besteld ambulancevervoer (Engelse titel: Scheduling elected ambulance transportation)

Transcription

1 Technische Universiteit Delft Faculteit Elektrotechniek, Wiskunde en Informatica Delft Institute of Applied Mathematics Het inplannen van besteld ambulancevervoer (Engelse titel: Scheduling elected ambulance transportation) Verslag ten behoeve van het Delft Institute of Applied Mathematics als onderdeel ter verkrijging van de graad van BACHELOR OF SCIENCE in TECHNISCHE WISKUNDE door LIANNE BRUIJNS Delft, Nederland Augustus 2015 Copyright 2015 door LIANNE BRUIJNS. Alle rechten voorbehouden.

2

3 BSc verslag TECHNISCHE WISKUNDE Het inplannen van besteld ambulancevervoer (Engelse titel: Scheduling elected ambulance transportation LIANNE BRUIJNS Technische Universiteit Delft Begeleider Dr.ir. J.T. van Essen Overige commissieleden Dr. D.C. Gijswijt Drs. E.M. van Elderen Augustus, 2015 Delft

4

5 ABSTRACT In this research, we constructed a model which makes an optimal schedule for the transport of patients in ambulances. These transportation are called requests. This scheduling problem is an example of Dial-a-Ride Problem (DARP). We define a Mixed Integer Linear Program (MILP), which consists of an objective function and constraints. These constraints are needed to provide a schedule in which working times and patients inconvenience is taken into account. Also the constraints which provide a appropriate and feasible route are described. To solve the MILP, we use exact solving methods. Another option is to use heuristics, but during this research we decided to only apply exact solving methods. The method used, is the Branch-and-Cut algorithm used in CPLEX. Lianne Bruijns Delft, Augustus 2015 v

6

7 CONTENTS 1 Introduction 1 2 Problem formulation 3 3 Exact solution methods for DARP Branch-and-bound Cutting planes Branch-and-cut Results Static model Dynamic model Comparing the static and dynamic model Discussion 27 A Schedule 29 B Tabu Search 31 C Data 33 Bibliography 35 vii

8

9 1 INTRODUCTION Ambulance transport is a familiar concept for emergency transportation. However, ambulances are also used for transport which is scheduled in advance. In the Netherlands, 33% of the transportations are scheduled transportations, which are known in advance [2]. This means they are no emergencies, but mostly journeys between the house of a patient and a hospital. Arrangements about the place and time of the execution of the request are made. To make sure emergency calls can be executed when needed, scheduled ambulance transportation is executed with another group of vehicles than than the group whereby emergency requests are executed. In the Netherlands, there are three types of urgency, which implies the group of vehicles in which a ride is executed. The A1-urgency ambulances transport patients which are in critical condition. A2-urgency ambulances transport patients who are not in mortal danger, but they need to be medicated as fast as possible. A1-urgency s and A2-urgency s are executed by ALS (Advanced Life Support) ambulances [6]. The urgency which is in the centre of attention in our problem, however, is the B-urgency. This type of transport does not need to be executed as fast as possible, but is planned in advance. B-urgency s are executed by BLS (Basic Life Support) ambulances. However, some regions only use ALS ambulances, so they need to split their vehicle fleet into two groups, for the different type of usage. Transportation which is planned before its execution, is known as Dial-A-Ride Problems (DARP). One can dial a ride and then the request will be scheduled, given its requested start and/or end time. DARP is a special case of the Pickup and Delivery Problem (PDP). This class of vehicle routing problems contains problems in which people or objects have to be transported between different locations. DARP is an example of a one-to-one PDP, which means that each requests contains a given start and destination location. Other PDP s are; many-to-many, in which any vertex can be a source or destination for any commodity (an example of this problem is the distribution of a product from the factories to the customers), and one-to-many, in which one depot is given and the other vertices are the customers that have to be serve [4]. The goal of DARP is to make a schedule for the transportation request. In our ambulance problem, we have requests arriving throughout the day, which need to be executed 1

10 2 1. INTRODUCTION within a given time window (to make sure a patient is served around the time agreed with the patient). Some requests are known beforehand, which is the static part of the problem. The dynamic part of the problem is contained in the requests which are known only just before the request has to be executed (which are coming in throughout the day). The dynamic element distinguishes DARP from PDP. For DARP, when a request comes in, it has to be executed the same day, sometimes even in the same hour. For scheduling, this means that we have to adjust the schedule during the day when requests are arriving. When considering a static PDP, all requests are known beforehand. When considering DARP, it is necessary to have a program which can schedule within a short time, such that the adjustments can be executed by the vehicles the same day. To make a schedule, we need to specify an objective. For DARP, there are many choices for the objective function. The objective function can be minimising the number of vehicles used, or minimising the driving time or total costs of the journeys. However, for the patient, it is important that the vehicle arrives in time, because waiting time is undesirable. In our problem, the goal is to minimise the patients inconvenience, measured by the deviation of the scheduled start and travel times compared to the desired start and travel times. We assume that the driving time for a request is known beforehand and that the schedule will not deviate from those times. The goal of our project is to provide a model for the region Utrecht, the Netherlands, in which the B-urgency type of transportation can be scheduled, considering various conditions. These conditions are described in Chapter 2. In Chapter 3, we explain the exact solving methods for our problem. In Chapter 4, we describe the results of our research. In Chapter 5, we discuss our results.

11 2 PROBLEM FORMULATION In this chapter we describe the model which schedules the requests. This model consists of an objective function, which describes what we want to minimise and maximise. It also contains several constraints, which give restrictions on the routes of the ambulances, the working time and driving time of ambulances. We have the following model: Consider a graph H = (N,E) with N = {0,...,n + 1} the set of requests represented as nodes (i, j N ) and E the set of arcs between those nodes. The first and last node, 0 and n +1, denote the start and end depot. For every request i, we have a duration of the trip d i, a start point SP i, an end point EP i, and the desired start time of the request ST i. To make a schedule, we need to know what route a vehicle has to follow. This route is based on the start and end points of the requests. For any arc between two nodes, the driving time DT i j is known. We also have a set of vehicles K with known start and end times for each vehicle k K (ST V k and ET V k ) of the working shifts. For every request, the day is known, such that we can schedule with the right fleet of vehicles. If request j is served right after request i with vehicle k, then X k i j = 1. Otherwise, X k i j = 0. For every request, we denote the scheduled start time with B i. For the start and end depot, the depart time and arriving time are given by B0 k and B n+1 k, for each vehicle k, respectively. For every request i, a time window is given in which the request needs to be served. Because we want to minimise the patients inconvenience, we need a way to measure this. In our model, the only way to dissatisfy a patient is to arrive too early or too late at the pickup location. So we measure the accuracy by comparing the requested start time with the scheduled one. The used objective function λ B i ST i (1 λ) i N X k i j i N j N k K consists of two parts we want to minimise. First, i N B i ST i denotes the difference between the scheduled and requested start time. For requests which are not executed in the schedule, B i is automatically set to ST i, because we minimise the difference between these 3

12 4 2. PROBLEM FORMULATION two values. The consequence of this is that we need to include the requirement that as many requests as possible need to be scheduled. Otherwise, the model will set the scheduled driving times equal to the requested, without really scheduling those requests. The second part of the objective function ensures that as many requests as possible are executed. Because of the importance of hospital visits and other businesses for which ambulances are needed, the main focus lies on scheduling most of the requests. The consequence of this is that the patients inconvenience is put to the test. This focus is given by the parameter λ, which gives the weights of the objective function. The model we want to use, is a Mixed Integer Linear Program (MILP). This means the solution only consists of integers and the objective and constraints need to be linear. Our MILP resembles the model used by Cordeau [5]. Integer programming problems are proven to be N P hard. Note that our objective function is nonlinear. To formulate our model as an MILP, we need to linearize the objective function. To make B i ST i linear, we introduce two extra positive integer variables; H + and H. We define: i i H + i ST i B i, i N (2.1) H i B i ST i, i N (2.2) Then B i ST i = H + i + H i, i N (this equality holds because we are minimising B i ST i ), so the program picks H + = 0 if ST i i B i 0, H + = ST i i B i if ST i B i > 0, H = B i i ST i if ST i B i 0, H = 0 if ST i i B i > 0 Using this, we can solve the MILP, because only linear constraints are considered.

13 5 We now give the objective function and time corresponding constraints. Minimise λ (H + i + H i ) (1 λ) X k i j (2.3) subject to i N X k i j j N,j ik K X k i j i N,i j k K i N X k i j X k j i i N i N j N k K 1, i N \ {0,n + 1} (2.4) 1, j N \ {0,n + 1} (2.5) = 0, j N, k K (2.6) X k 0j j N,j 0 X k i,n+1 i N,i n+1 ( B j B0 k + DT 0j M 1 X k 0j ( ) B j B i + d i + DT i j M 1 X k i j k K ( Bn+1 k B i + d i + DT i,n+1 M 1 X k i,n+1 = 1, k K (2.7) = 1, k K (2.8) ), j N, k K (2.9), i, j N, k K (2.10) ), i N, k K (2.11) e i B i l i, i N, k K (2.12) ST V k B k 0 B k n+1 ET V k, k K (2.13) X k i j {0,1}, i, j N, k K (2.14) B i 0, integer, i N (2.15) B0 k, B n+1 k 0, integer, k K (2.16) Equation (2.3) is the objective function. The first part of the equation measures the deviation between the requested and scheduled starting time. The second part counts number of scheduled requests. Constraints (2.4), (2.5) and (2.6) ensures that each request is served at most once and only one vehicle can serve a request. Constraints (2.7) and (2.8) make sure that each vehicle starts and ends its route at the start depot (in our model the start depot is equal to the end depot: 0 = n + 1). Constraints (2.9), (2.10) and (2.11) define the start time of the requests. Constraint (2.12) enforces each request satisfies its given time window [e i,l i ]. Constraint (2.13) ensures that each request is served within the given working times of the vehicles and that every end depot is visited after the start depot.

14

15 3 EXACT SOLUTION METHODS FOR DARP In this chapter, we describe several algorithms to solve DARP. Although the computation time for solving an N P hard problem to optimality may be infinite, there are some algorithms widely used to solve Integer Linear Programming (ILP) problems. The algorithms we describe, are used in many approaches for solving DARPs. To make the time of searching for a solution shorter, we use these algorithms. These algorithms are using strategies which split up the solution spaces by excluding some non integer solutions. The solution space consists of all possible solutions for the problem. When splitting up this space, the set of possible solutions decreases, because we remove the non integer solutions. This implies that the search will be shorter, because less possibilities have to be considered. We use CPLEX to solve the MILP. CPLEX uses a Branch-and-bound algorithm for solving MIP. This Branch-and-bound uses feature like cutting planes and heuristics to find integer solutions. In this chapter, we explain the algorithms used in CPLEX Branch-and-bound Branch-and-bound is a widely used algorithm for solving ILP problems. To explain how this algorithm works, we consider a minimization problem with the objective function f (x), where x is a vector. The idea of the algorithm is to find an integer solution by using LP-relaxation (Linear Programming-relaxation, an ILP without the integer constraints), because solving an LP takes much less time than solving an Integer Program (IP). LP-relaxation means that we remove the constraint that the solution has to be integer. This transforms a N P hard problem into a related problem which is solvable in polynomial time. The Branch-and-bound algorithm is based on the partition of the solution space in subspaces [7]. The algorithm consists of two main components, which gives this algorithm his name. Branching is partitioning the solution space X into subspaces X 1,..., X n, whose union covers the whole space. Bounding is computing the upper and lower bounds for the minimum value of f (x) in a subspace. 7

16 8 3. EXACT SOLUTION METHODS FOR DARP Consider the ILP The LP-relaxation of this ILP is min f (x) (3.1) subject to Ax b (3.2) x 0, integer (3.3) min f (x) (3.4) subject to Ax b (3.5) x 0 (3.6) When solving the LP relaxation, we obtain a solution x 0, which is not integer in general. The value of f (x 0 ) is a lower bound on the optimal objective value f (x ), with x the optimal solution. To find an integer solution, we partition the solution space in two parts. Let x 0 i be a non integer component of x 0, then we can make two sub problems: and min f (x) (3.7) subject to Ax b (3.8) x 0 (3.9) x i x 0 i (3.10) min f (x) (3.11) subject to Ax b (3.12) x 0 (3.13) x i x 0 i (3.14) When solving those sub problems, their solutions can also be non integer. In that case, we partition the sub problems into smaller sub problems. When the case occurs that some sub problem has an objective function value larger than the best integer solution found so far, than it is not necessary to search this branch further in this sub problem. We now solve an example with Branch-and-bound: min z I P = 4x 1 + x 2 (3.15) subject to 7x 1 2x 2 14 (3.16) x 2 3 (3.17) 2x 1 2x 2 3 (3.18) x 1, x 2 0, integer (3.19) To solve our ILP, we first search for a solution assuming our problem is an LP, so we drop the

17 3.1. BRANCH-AND-BOUND 9 restriction that our solution should be integer from consideration. The search for a noninteger solution for an ILP is called the LP-relaxation. In Figure 3.1, we see the LP-relaxation of our ILP problem. The green, red and blue area represent the areas of inequalities (3.16), (3.17) and (3.18), respectively. The blue nodes denote the integer solutions for x. Our goal is to find an integer solution, so one of those blue nodes represent the optimal solution. Because we want to minimise z, the optimal solution lies on the right hand side of line z. Figure 3.1: LP-Relaxation The first LP-relaxation is denoted by node 0 in Figure 3.2. We introduce some notation. After bounding the solution space, we obtain two subspaces which we have to observe. This results in a new node in the search tree. The solution of the LP-relaxation in node n is given by x n LP, the value of z by zn LP. The LP-relaxation of the given ILP problem gives x 0 LP = [ ] (the red point in Figure 3.1) and z 0 LP = Because we want to minimise z I P, we know z I P z LP. The value of z LP is a lower bound for z I P, denoted by z. In our example, we know now that z I P z 0 LP = 8 = z and z I P + (this is the upper bound for z I P, denoted by z). In x LP, x 1 is non integer. We divide our solution space by including the constraint x 1 2 or the constraint x 1 3, because our non integer x 1 = 20 7 is in the interval [2,3]. In case x 1 3 (node 1), we see that the LP-relaxation is infeasible, i.e. the solution space becomes empty.

18 10 3. EXACT SOLUTION METHODS FOR DARP [ ] 2 For x 1 2 (node 2) we obtain x 2 LP = 1 and z 2 LP = Then z2 = 7. We divide our 2 solution space by x 2 1 and x 2 0 ( x 2 = 0), because x 2 = 1 [ ] 2. 2 For x 2 1, we obtain x 3 LP =, z 3 1 LP = 7. Because x3 LP is integer, z3 = 7. Then z = z = 7. [ ] 2 For x 2 = 0, we obtain x 4 LP =. But then constraint (3.18) no longer holds. So this so- 0 lution is infeasible. [ ] 2 The optimal solution is x I P =, z 1 I P = 7. An overview of all the steps is given in Figure 3.2. Figure 3.2: Search tree from the Branch-and-bound There are many ways of choosing from which sub problem the search will continue. One option is the Depth-first method, which searches in one branch until an integer solution is found. Another option is to look for the node with the lowest lower bound, because finding the optimal solution from there seems reliable (best-node-first) Cutting planes An algorithm which is often used to solve ILPs is the cutting planes algorithm. The algorithm works with a single linear program. When applying the algorithm, new constraints are added to improve the search. These new constraints reduce the feasible region until an optimal integer solution is found. This Cutting plane method is developed by Ralph Gomory. The cuts obtained by this method are called Gomory cuts. Although Branchand-bound is used more often in practice, cutting planes has left its mark on integer programming. The algorithm has helped research which led to more efficient algorithms. It is also used in the Branch-and-cut algorithm, which is a combination of cutting planes and Branch-and-bound. We consider the Branch-and-cut algorithm in the next section. We ex-

19 3.2. CUTTING PLANES 11 plain how cutting planes works by an example. We use the same ILP as in Section 3.1. In this case, we observe a maximization problem (min 4x 1 + x 2 = max 4x 1 x 2 ). max z I P = 4x 1 x 2 (3.20) subject to 7x 1 2x 2 14 (3.21) x 2 3 (3.22) 2x 1 2x 2 3 (3.23) x 1, x 2 0, integer (3.24) We add an extra slack variable to each inequality; x 3, x 4 and x 5, so we get equalities. max z I P = 4x 1 x 2 (3.25) subject to 7x 1 2x 2 + x 3 = 14 (3.26) x 2 + x 4 = 3 (3.27) 2x 1 2x 2 + x 5 = 3 (3.28) We create with the simplex method an optimal tableau from which we can start our cutting planes algorithm. x 1 x 2 x 3 x 4 x 5 z = x 3 = x 4 = x 5 = z = x 1 = x 4 = x 5 = z = x 1 = x 2 = x 5 = We want to create an extra constraint for our ILP. To gain this constraint, we take an equality from the last tableau, in this case we choose x 1. Then x x x 4 = 20 7 (3.29) x 1 2 = x x 4 (3.30) 6 From this the Gomory cut is as follows: x x 4 0. Substitution of slack variables x 3 and x 4 as given in (3.26) and (3.27) gives the following

20 12 3. EXACT SOLUTION METHODS FOR DARP equation: (14 7x 1 + 2x 2 ) 2 7 (3 x 2) 0 From this inequation it follows that x 1 2. We add this constraint to our ILP: max z I P = 4x 1 x 2 (3.31) subject to 7x 1 2x 2 14 (3.32) x 2 3 (3.33) 2x 1 2x 2 3 (3.34) x 1 2 (3.35) x 1, x 2 0, integer (3.36) Figure 3.3: Cutting plane constraints In Figure 3.3, we see the constraints of our ILP. The green, red and blue area represent the areas of inequalities (3.32),(3.33) and (3.34), respectively. The added constraint (3.35) is represented by the black line (the right hand side is the area which remains after cutting). Repeating the steps, slack variables are added to the ILP and the simplex method is

21 3.2. CUTTING PLANES 13 executed. We show two more cuts of our problem. x 1 x 2 x 3 x 4 x 5 s 1 z = x 1 = x 2 = x 5 = s 1 = z = x 1 = x 2 = x 3 = s 1 = From the row x 3 follows 12 x 3 5x 4 4x 5 = x 5, which gives us the Gomory cut: x 5 0. From this cut and (3.28) follows that x 1 x 2 1. We add s 2 = x 5 to the tableau. x 1 x 2 x 3 x 4 x 5 s 1 s 2 z = x 1 = x 2 = x 3 = s 1 = s 2 = z = x 1 = x 2 = x 3 = x 4 = s 2 = From row x 2 as well as from row x 4 follows x 1 x 2 1. We add s 3 = x 5 to the tableau.

22 14 3. EXACT SOLUTION METHODS FOR DARP x 1 x 2 x 3 x 4 x 5 s 1 s 2 s 3 z = x 1 = x 2 = x 3 = x 4 = s 2 = s 3 = z = x 1 = x 2 = x 3 = x 4 = x 5 = s 3 = We now find an optimal solution z = 7 with x = 7 = 3s 1 s 2 = 7 + 2x 1 + x 2 ). [ ] 2 (this follows from the tableau: 1 Figure 3.4: Cutting plane constraints after more iterations In Figure 3.4, the added constraints are represented by the black lines and its areas. The darkest area represents the solution space in which we are still looking for a solution. Note our solution is the cross point of the extra constraints.

23 3.3. BRANCH-AND-CUT Branch-and-cut As said before, Branch-and-cut is a combination of Branch-and-bound and cutting planes, and used in CPLEX. We start with an ILP to solve, just like when using Branch-and-bound or cutting planes: min f (x) (3.37) subject to Ax b (3.38) x 0, integer (3.39) We give a Branch-and-cut algorithm to solve an ILP [1]. Let L denote the set of active nodes in the Branch-and-cut tree. This are the nodes in which a optimal solution could be. z l is a lower bound for the optimal value of the current sub problem 1. Let L be all the active nodes in the ILP. Set the upper bound to be z = +. Set z = for all problems l L. 2. Choose an unsolved problem l L and delete it from L. 3. Compute the lower bound z l by solving the LP-relaxation. If problem l is infeasible, go to step 2 until the list is empty. Otherwise, let x l be an optimal solution and set z l := f (x l ). 4. If x l is integer, problem l is solved and we found a feasible solution of l, if z > z l, set z := z and delete all sub problems l with z l z from L. 5. If x l is non integer, look for cutting planes and add them to the LP-relaxation. 6. Go to Step 3 until no more violated inequalities can be found. 7. Split l into two sub problems and add them to L (as in Branch-and-bound). 8. Go to Step 2 until L is empty. This algorithm leaves it up to the user the choice how to choose the problems we want to search further or how to split the problem into sub problems. This is also the case when Branch-and-bound is used. In our case, CLPEX decides how to search for an integer solution.

24

25 4 RESULTS The aim of this project is to develop a program which can create a schedule for ambulances in which requests are processed. The scheduling needs to be done in real time, because the requests have to be executed the same day. Our model is based on data from the region Utrecht. We collected data from to For every day, it is known which requests have to be served. The requested start time of each request is given, just like the driving time of the request. From this information, we know at which time a request ends. In our model, we use the software system AIMMS with the solver CPLEX. AIMMS is useful for research projects in mathematical programming. CPLEX is a high performance solver for Linear Programming (LP), Mixed Integer Programming (MIP) and Quadratic Programming (QP) problems. Our model is an MIP problem [8]. The data of the requests contains information about the start and end locations of the requests. This information is given in 6 places alphanumeric postal codes. For each request i, we know the driving time d i. We have also obtained information about the driving times between 4-digit postal codes (the district information is missing).to make a route between the different requests, we need to know the driving time from an end point from request i to a starting point from request j. If the driving time between to different 6-digit postal codes is known, we use this information (if the arc (EP i,sp j ) between node i and j corresponds to a node n such that SP n = EP i and EP n = SP j, then DT i j = d n ). If not, we use the driving times from the 4-digit postal codes data. Because we use the 4-digit postal code driving times to approach the 6-digit postal codes driving times, the scheduled driving time will deverge from the real time. This driving time approach affects the start times in constraints (2.9), (2.10) and (2.11). For every day of the week, the number of ambulances and their working times are known. For Monday until Friday, we have 10 ambulances available, each having their own start and end time. On Saturday, there are 7 ambulances available and on Sunday 5. An important fact is that for every moment of the day, at least one ambulances is available, which means that there is always at least one ambulance available which can handle requests (see also Figure C.1). 17

26 18 4. RESULTS For each day in the planning horizon, the model is solved such that the requests for that day are assigned to one of the available ambulances if possible. First, we make a schedule assuming that all requests are known at the beginning of the day (this is the static model). When scheduling the requests, we take into account the release time of the requests (the time a request is known by the distribution office) and the requested start time of the request. A request can be executed in a time window, starting at the release time of a request and ending a given time after its requesting starting time. What we actually want, is to schedule all the requests (so (2.4) and (2.5) have =-signs), but AIMMS cannot find a solution for days with a lot of requests. Therefore, we added the -signs in constraints (2.4) and (2.5), such that not every request has to be executed. This is the reason the objective function contains a part which ensures as most as possible requests are executed. Next, we will implement a rolling horizon such that requests are received and scheduled only after their release times, so not all the requests are known at the start of a working day. This is our dynamic model. In the dynamic model, the model starts scheduling the requests known at the start of the day (release time =0). Every hour, the model checks if new requests have been received, and if that is the case, those requests will be scheduled with respect to the requests already executed by a vehicle. It is not possible to cancel requests that already have been executed. It is however, possible to cancel requests when scheduling the new and removing an old request gives a lower deviation between the requested and scheduled starting time Static model We did a search for the best λ. To start our search, we took the static model and observed the solutions for 14 days. We choose this amount, to avoid long computation times. AIMMS works better when only little amount of data is given. We generated random days; under the condition that each weekday is represented by two days of the twelve. We used the following days:

27 4.1. STATIC MODEL 19 Day number Weekday Date 6 Sunday Thursday Saturday Saturday Monday Friday Wednesday Sunday Tuesday Thursday Friday Tuesday Monday Wednesday To start our search, we set the time windows quite large: Time window = [Release Time, Start Time +240], with Time window, Release Time and Start Time in minutes (Start Time in this context is the requested start time). For λ = 1 and λ = 0, no satisfying solution can be found. For λ = 0, the objective function does not depend on the difference between the requested and scheduled start time, which gives a schedule in which most of the requests are executed, but the patients inconvenience is huge. For λ = 1, the difference between the requested and scheduled starting times is minimal, but that implies that no requests are executed (because when a request is not scheduled, the model can set B i = ST i, which gives i N B i ST i = 0). So setting λ = 1 is no option. From these extreme cases, we found the value for λ must not be too large, so we chose small values to observe. (a) B i ST i, i N Time window = [RT i, ST i + 240] (b) i N j N k K X k i j, Time window = [RT i, ST i + 240] Figure 4.1: Objective function splitted up (RT=Release Time) In Figure 4.1a and Figure 4.1b, we see the total differences (= i N B i ST i ) and the number of scheduled requests (= i N j N k K X k ) for each day of our test data for different values λ. The time windows are set quite large, so more requests can be scheduled. i j In Figure 4.2, we see the consequences for the objective function for λ = 0.2 and λ = and different time windows. We see that for different values of λ, the number of scheduled requests does not vary much from each other (see Figure 4.2a and Figure 4.2b). Even for a small value of λ (λ = ), when the weight of scheduling requests in the objective

28 20 4. RESULTS function is large, not all requests will be scheduled. For choosing our parameter, it is more important to look at the difference and the computational time, so we therefore decide to consider larger values for our parameter. In Figure 4.2c and Figure 4.2d, we can see that the scheduled times vary much from the requested times when a small value of λ is chosen, just as expected. Moreover, when a larger time window is used, the total difference will also grow, because our constraints allow this larger total difference (by setting the time window larger, the model has more space to schedule a request). In Figure 4.3a and Figure 4.3b, we can see how the total difference enlarges when a larger time window is chosen. We see for the smallest value of λ, the total difference blows up. From this fact, we decide not to use too small values for λ. (a) X k i j, Time window = [RT i, ST i ] i N j Nk K (b) X k i j, Time window = [RT i, ST i + 240] i N j Nk K (c) B i ST i, Time window = [RT i, ST i ] (d) B i ST i, Time window = [RT i, ST i + 240] i N Figure 4.2: λ = 0.2 and λ = i N In Figure 4.4, we see the gap, the solving time, the total differences (= i N B i ST i ) and the number of scheduled requests (= i N j N k K X k ) for each day of our test data, i j for λ = 0, 004. The solving time is given in seconds, the gap in percentages. Note that we added a constraint to the solving time to reduce computation time. The maximum allowed solving time for each day was 200 seconds. Next, we take a closer look at what the parameter λ causes when λ [0.2,025]. We varied the time windows, with x = {0, 30, 60}. The results were remarkable. In the left column of Table 4.1, the values for λ are given.

29 4.2. DYNAMIC MODEL 21 (a) B i ST i, λ = 0.2, i N Time window = [RT i, ST i + x] (b) B i ST i, λ = , i N Time window = [RT i, ST i + x] Figure 4.3: Different time windows Computation time B i ST i i N X k i j i N j N k K λ = x = Table 4.1 We see the computation times increases when the Time Window gets larger. The more options there are to schedule a request, the longer it takes before a schedule is made. Moreover, the deviation from the requested start time becomes only larger when the time window gets wider. From this point, it seems reasonable to choose a small time window. The disadvantage however, is that in our test data for the case x = 0, there are executed 7 requests less than with the time windows x = 30 and x = 60. Note that despite the fact the values of the objective functions do not vary much when changing λ, the computation time decreases when λ gets larger. From this results, λ = 0.24 seems a reliable parameter in our model. Our aim is to provide a model which generates the best possible schedules. From Table 4.1, we see that for λ = 0.24 the computation times are short Dynamic model As already said, the dynamic model differs from the static model because of requests are received throughout the day, and not already known at the start of a working day. To

30 22 4. RESULTS (a) Gap (b) Solving time (c) B i ST i (d) Scheduled requests i N Figure 4.4: Static model: λ = 0.24 simulate this dynamic situation in our model, we added a rolling horizon. The idea of this model, is that it can be executed during the day. The model is as follows: The working day starts at 7.30AM. At this time the scheduling starts. With the known requests which already has been received at that moment, a schedule is made. Every hour the schedule is updated. First, we checked if new requests have arrived. When this is the case, the schedule will be updated.if requests already are executed, the route and start time of the execution of those requests are locked (because we cannot adjust the execution of those requests). The computation time of the dynamic model is considerable larger than for the static model, because computations have to be performed every hour. We bounded the computation time for every execution, so the computation time of the simulation will not take too long. We set the bound to 100 seconds. For our simulation, it is sufficient to generate credible schedules, and in real life you also do not have much time to wait for the new schedules. Another way to reduce waiting time while simulating, is to accept a little gap between the best LP-bound and the best solution. In this way, the computation time will be less if a sufficiently well solution is found. We accept a gap from 10%. To observe the influence of the parameter λ in the objective function for the dynamic model, we executed the model with our test data. The results can be found in Figure 4.5. We see the number of scheduled requests does not differ much, when we adjust the value of λ. For the deviation between the requested and scheduled starting time however, we see

31 4.3. COMPARING THE STATIC AND DYNAMIC MODEL 23 the smaller λ, the higher the deviation is. From this point of view, it seems wise to choose a larger value of λ. (a) B i ST i, Time window = [RT i, ST i + 60] i N (b) X k i j, Time window = [RT i, ST i + 60] i N j N k K Figure 4.5: Comparing λ 4.3. Comparing the static and dynamic model We have chosen to use small values for λ, so we emphasise on maximising the number of requests executed. For different values of λ, we have runned both the static and dynamic model. We have fixed the time windows (time windows and release, start and end time and x are given in minutes): e i =RT i l i =ST i + x In this section, we denote the different executed models by the following code: D stands for the dynamic model, S for the static model. In the figures, the number after D and S denotes the value of x. For our random chosen days, it is not possible to schedule all requests. Note that our

32 24 4. RESULTS model counts only the total sum of the differences. This means there is no difference in served two requests, each with an hour delay, or one on time and one with two hours delay. We restrict the delay per request by the time window constraints e i B i l i. The more narrow this time window is set, the less excessive delay is possible. For the ambulance provider, it is important that also as much requests as possible needs to be served in time. The requests that cannot be scheduled, have to be executed by ALS ambulances, which has impact on the coverage for emergency calls. However, our model is not capable of scheduling all requests, even when no time window constraints are given. So it is inevitable that other vehicles have to be used. For λ = 0.24, we see the results of both the static and dynamic model in Figure 4.6, Figure 4.7 and Figure 4.8. As we can see in Figure 4.6a, Figure 4.7a and Figure 4.8a, the dynamic model provides less deviation between the requested and scheduled start time. But this is connected to the fact that less requests can be executed in the dynamic model (Figure 4.6b, Figure 4.7b and Figure 4.8b). The number of less executed requests as well as the deviation are quite small.

33 4.3. COMPARING THE STATIC AND DYNAMIC MODEL 25 (a) B i ST i (b) X k i j i N i N j N k K Figure 4.6: λ = 0.24, Time window = [RT i,st i ] (a) B i ST i i N (b) X k i j i N j N k K Figure 4.7: λ = 0.24, Time window = [RT i,st i + 30] (a) B i ST i (b) X k i j i N i N j N k K Figure 4.8: λ = 0.24, Time window = [RT i,st i + 60]

34 26 4. RESULTS (a) B i ST i (b) X k i j i N i N j N k K Figure 4.9: λ = 0.28, Time window = [RT i,st i + 30] (a) B i ST i (b) X k i j i N i N j N k K Figure 4.10: λ = 0.28, Time window = [RT i,st i + 60] For λ = 0.28, only a little difference is visible, comparing to λ = For Time Window = [RT i, ST i ] (so the time window is as narrow as possible, the Release Time left out of account), there is no difference between the static and dynamic model. In Figure 4.9 and Figure 4.10, we see the objective function split up for time window with x = 30 and x = 60. From this figures as well as from the data for λ = 0.24, we can conclude the static model is capable to schedule more requests than the dynamic model, but that does not imply that the effect is less deviation between the requested and executed starting time. On the contrary, the static model allows more deviation than the dynamic model. We see the two parts of the objective function ( i N B i ST i and i N j N k K X k i j ) are strongly correlated, and it depending on which factor weights more, the parameter λ has to be chosen. For the Time Window, we see that bigger time windows lead to more executed requests. Therefore, it is reasonable to set the time window on [RT i, ST i + 60], or at least x 0.

35 5 DISCUSSION In Chapter 4, we described how we have build the model. Depending on what factor is more important to the executor of the requests, the objective function can be chosen. In our case, the B-urgency request of Utrecht, the Netherlands, our model is not capable of scheduling all the requests, as a result of the fact that there are too many requests and too few vehicles to execute them. Therefore, it is wise to accentuate the prevention of deviation of the requested starting time. Our observed values of the parameter of the objective function (2.3) are between λ = 0.2 and λ = 0.3. There are a number of adjustments we can do to improve our model. One adjustment is observing more exact driving times, so we can provide a more accurate schedule. Another option is to schedule each time a new request has come in, instead of a fixed time interval in which we check if new requests has come in. In our model, a disadvantage of this option is that the computation time of the model will grow, because we have to check every minute if a new request is received. A well known objective is minimising the number of vehicles used. In our case, it probably would be hardly possible to reduce the number of vehicles used at a day, because we actually have not enough vehicles available to serve all requests. Another option for our model, is to require every request need to be scheduled (so we strengthen the constraints with respect to the number of requests scheduled), and therefore add a slack vehicle to our fleet. Every time a request is paired up with this slack vehicle, a penalty is given. The objective function will then have the goal to minimise the penalties. Another interesting thing is considering heuristics and implementing them in the model. Our dynamic model is based on a scheduling process per hour. The remaining time, in which no schedules are made, it is possible to apply an heuristic which optimises the existing schedule during the execution. An example of such an heuristic is Tabu Search. Tabu Search is a heuristic which appears quite often in papers about dial-a-ride problems. This heuristic starts with an initial solution and searches for a better solution. This initial solution is found with an exact algorithm, for example one from Chapter 2. In short, the heuristic searches the neighbourhood of a given solution. Then the heuristic will find solution, some better and some worse than the current solution. Then the search for a better solution starts from the last best solution. The old solution is declared tabu 27

36 28 5. DISCUSSION such that the program does not find old solutions as the best (and ends up in a cycle). The benefit of this heuristic, is that the procedure does not stop when a local optimum is found. The TS accepts also worse (infeasible) solutions if a better solution is not available or declared tabu, which ensures that the search can be extended to a larger solution area. Because the initial solution is already available, it is possible to only run the TS when computation time is available. If not, you will have the initial solution which can help you to serve the requests, even tough it is not the best solution you wished to have. In [3], a TS method is described. A summary of this type of Tabu Search is given in Appendix B. Concluding, the model can be optimised by using more accurate data for the driving times. Also the objective function can be adjusted. Using other exact solving methods or even heuristics will provide more insights in the working and effectiveness of our used programs. Looking at our constraints

37 A SCHEDULE For λ = 0.24, x = 60 we create the schedules for all our test data. An example of the schedule is given for day 185 (Thursday ), one of our 14 days. Request 0 and are the start and end depot, respectively. Request i stands for the end point of request i which is served before the ambulance drives to the start point from request j. Request j is served right after request i. The Start time is given in minutes. The ST Ambulance can be found in Appendix C. This schedule is generated by AIMMS with CPLEX. 29

38 30 A. SCHEDULE Day Vehicle Request i Request j Start Time ST ambulance ST ambulance ST ambulance ST ambulance ST ambulance ST ambulance ST ambulance ST ambulance ST ambulance ST ambulance

39 B TABU SEARCH In [3], a two-phase heuristic is used to construct schedules for vehicles. First a initial solution is found by a simple insertion algorithm, which starts with a solution based on the already known requests, and new incoming requests are augmented to the schedule during the day. We call the start solution x 0. On each iteration l, a new non-tabu best solution is chosen in the neighbourhood N (x l ) of the current solution x l. As already said, the previous solution is declared tabu for κ iterations. In this model of hospital transportation, the Tabu Search stops either when the model needs its computational time for augmenting new requests or when a maximum number of iterations has achieved. A better solution will be obtained when there is more time between incoming requests, because that time can be used to improve the solution by using Tabu Search. In this model the Tabu Search contains two types of moves: inter-route and intra-route moves. The first considers a request with the largest penalty (in our own ambulance problem it is the request which scheduled starting time varies most comparing to their requested starting time) and compares the result of placing this request in on another vehicles route. For example, when request i is first served by vehicle A, then the heuristic removes request i from the route from A and places it on the route of another vehicle. The condition of the largest penalty is necessary because of the limited computational time. Important to remember is the fact that also infeasible solutions are accepted in this heuristic. This can be violation of the given time windows for example. The violation is measured by a penalty cost function (for example f (x) = c(x) + αq(x) + βp(x) + γw(x), with c(x) the total routing cost and p(x), q(x) and w(x) the total violation of duration, time window and ride time, respectively). This cost function is used as a relaxation mechanism which ensures that a larger solution space is considered. If x is feasible with respect to the constraints, the associated parameter is multiplied by 1 + µ, otherwise it is divided by 1 + µ, µ > 0. In this way we ensure the search will be more intensively in promising regions. 31

40 32 B. TABU SEARCH To avoid cycling when searching for a better solution, frequently performed moves need to be penalised. This means, for adding a request i to vehicle k a penalty factor is added. The more this happens, how larger the penalty gets. In the model for the transportation in hospitals, the intra-route moves are applied every κ iterations. In this step, the order of requests per vehicle is considered. When another order of requests gives a better result, the schedule will be adjusted.

41 C DATA Figure C.1: Working Times ambulances 33

42

43 BIBLIOGRAPHY [1] K. Aardal, G.L. Nemhauser and R. Weismantel Handbooks in Operations Research and Management Science", [2] Ambulancezorg Nederland, Uniform Begrippenkader Ambulancezorg", uniform-begrippen-kader-2013.pdf/, 2013, [Online; accessed 10-July-2015]. [3] Beaudry, Alexandre and Laporte, Gilbert, Teresa Melo and Stefan Nickel, Dynamic transportation of patients in hospitals", [4] Berbeglia, Gerardo and Cordeau, Jean-François and Laporte, Gilbert, Dynamic pickup and delivery problems", [5] Jean-François Cordeau, a Branch-and-Cut for the Dial-a-Ride Problem", Operations Research 54(3): , Physica B: Condensed Matter, [6] Nederlands Zorgautoriteit, Marktscan_ambulancezorg_2013_en_beleidsbrief.pdf, 2013, [Online; accessed 29-July-2015]. [7] Papadimitriou, H. Christos and Kenneth Steiglitz, Combinatorial Optimization: Algorithms and Complexity", publisher: Dover, [8] [Online; accessed 10-June-2015]. [9] Integer Programming", pdf/, [Online; accessed 10-July-2015]. 35