REALTIME DYNAMIC SCHEDULING

(1)

REALTIME DYNAMIC

SCHEDULING

T.H.J. Leunissen (10191828)

June 24, 2016

Bachelor Thesis

Credits: 18 EC Bachelor Artificial Intelligence Faculty of Science University of Amsterdam Supervisor Aysenur Bilgin Institute for Logic University of Amsterdam

Expert

Ahmed Mohamed Research Scientist British Telecom

(2)

Acknowledgements

Firstly I would like to thanks Tom from the British Language Teaching Centre who taught us a lot about Academic English in a mere four hours. Secondly I would like to thank my family and girlfriend for their time and formidable English. Furthermore, I want to thank my supervisors Ahmed Mohamed and Aysenur Bilgin for their guidance, help, and especially thank Aysenur for her honest critical view. Finally I want to thank Car2Go (electric vehicle rental company) for enabling me to drive to university and giving me time to think about traffic while being in it.

(3)

Abstract

An essential problem transport companies face is the Dynamic Vehicle Routing Problem, which describes the situation where a number of vehicles has to visit a set of locations with a created schedule. The creation of schedules is difficult because it is both a NP-complete problem, and it also has to take uncertain values into account. With the coming of smart algorithms, the first problem has received a lot of attention, however, the improvements in minimising uncertainty have not. In this paper, we look at the improvement of real time rescheduling as opposed to beginning of the day scheduling, thereby harnessing the advantage from recent improvements in real time travelling time predictions.

(4)

List of Figures

2.1 Overview of a data point in experiment . . . 6

3.1 Example of simulation #320 halfway through the day . . . 9

3.2 Example of random targets with euclidean shortest routes . . . 11

3.3 Example of random targets with shortest routes by Google Maps Routing API . . . 11

3.4 Incident on a road close to a roundabout. . . 13

3.5 Incident on one side of the motorway . . . 13

4.1 Values of address visiting time used in experiments . . . 18

4.2 The number of accidents that are active at the same time . . . 19

(7)

Chapter 1

Introduction

An essential problem transport companies face is the Dynamic Vehicle Routing Problem (Barbucha, 2013). This problem describes the situation where a number of vehicles has to visit a set of locations. A common example of this is the delivery of packages to customers. In most areas of logistics, these visits have to be scheduled beforehand. Creating precise schedules for these visits is an arduous process for two main reasons.

Firstly, the creation of optimal schedules is an advanced version of a travelling salesman problem, a typical example of a NP-complete problem (Papadimitriou, 1977). Therefore, brute force algorithms, which find an optimal schedule by simply checking all solutions, are very inefficient.

The second aspect is that the algorithm has to base its results on probabilistic values, which means that it can not be certain about the length of the trip, and must therefore take different travelling times into account.

Most scientific endeavours have focused on the first problem. Since the beginning of this century, many smart algorithms such as k-nearest neighbours (Tchrakian et al., 2012), support vector ma-chines (Zhang & Haghani, 2015), genetic algorithms (Moridpour et al., 2015) and neural networks (Van Lint et al., 2005), have proven themselves useful in the estimation of solutions to the travelling salesman problem. Due to a large number of novel approaches, it is difficult to determine which of these can be regarded as state of the art.

These smart algorithms also play a major role in the second problem of providing accurate and effi-ciently calculated travelling time predictions. In a travelling salesman problem, an optimal solution can be reached. This solution, however, can not be applied to the estimation of travelling time, since

(8)

traffic accidents, for example, simply cannot be predicted.

The biggest step that has been made in the estimation of travelling time is largely due to advances in otherwise unrelated fields of technology. Nowadays, data about vehicle movements is available from Internet connected devices such as navigation systems, as well as smartphones(Liebig et al., 2016). This information has a tremendous impact on traffic predictions; it is hard to think of a better predictor of traffic in the coming few minutes than the current traffic condition. Using data gathered during the day, Yao (Yao et al., 2015) found that estimations converge with the actual travelling time.

To harness this advantage, we do however need to take a different approach when creating a schedule at the beginning of the day and when looking at real time1 _{scheduling algorithms.}

1.1 Research question

Given this current state, research into a system which can use real time travelling information for schedules seems promising. We are especially interested in the advantage this allows over schedules created at the beginning of the day. To stay concise, we will narrow the field of research down to a single city: Amsterdam.

The choice for Amsterdam is manifold. To begin with, cities have more diverse traffic conditions than smaller towns. Furthermore, traffic in cites will also increase in the coming years (Barros et al., 2015) which will pose new challenges for the logistics sector and alike. In addition, Amsterdam is a city of beltways2with its two main ring roads called the Nassaukade3and the A10. As a city of belt roads, Amsterdam’s changing traffic flow hugely influences the travelling time.

Combining Amsterdam with our interest in the advantage of rescheduling, leads to the following research question:

How much does rescheduling using real time traffic information improve ETA (Estimated Time of Arrival) accuracy in the City of Amsterdam?

The hypothesis is that rescheduling during the day will produce better ETA accuracy than not doing so. This is because there is more information about current travelling times, as well as a more detailed view of the current vehicle positions.

1_{The concepts real time and short term are used interchangeably. However, ”short term” will be used to contrast}

”long term” whereas real time will be used to emphasise when the activity happens.

2_{A main road encircling a city, also called ring road. Mostly used to ensure stable traffic flow.} 3_{Also called Stadhouderskade and Mauritskade}

(9)

The development of a system capable of simulating a rescheduling algorithm, as well as comparing it to its non-rescheduling counterpart, is an important contribution to logistic companies who might consider the investment in real time scheduling. Secondly, it contributes to the advantages and disadvantages of scheduling and rescheduling, a comparison scarcely made in most literature.

(10)

Chapter 2

Theoretical context

The goal of this research is to investigate the effect of rescheduling on the ability of meeting goals in a service based organisation. This goal will be achieved by comparing the results of a goal-task system, in particular, by looking at one that does reschedule and one that does not. We do this by using a simulation, mainly for its property of being able to run the exact same simulation with different parameters. The simulation will generate the data on which the final conclusion will be based.

Section 2.1 discusses a theoretical background on the advantage of updating schedules. Section 2.2 gives a state of the art overview of travelling times and showcases the differences between long term and short term predictions. Section 2.3 is dedicated to the creation of a good simulation. Good simulations are ones that produce results similar to what a real world experiment would give. This section showcases a short search for the difference between long term traffic predictions and short term predictions.

The complete chapter serves as background information to create a better simulation and be able to have a better way of understanding the data our simulation will generate.

2.1 Advantage of rescheduling

An obvious fact to begin with is that rescheduling implies there is already and initial schedule. These schedules are created to best match goals to abilities; depending on the goal which has to be accomplished, schedules are made days, months, or years in advance.

(11)

One can imagine that during the time certain aspects, on which these schedules are based, change. Since we are scheduling, an easy property to think of is time, but there are other properties to consider, such as distance being travelled, the number of scheduled appointments that are met, or the amount of gas being used. The advantage of rescheduling, then, is the replacement of the current schedule with one that has preferable properties.

The British Telecom has identified the following causes which precede situations in which schedules are not met. Currently, these situations are handled by manual rescheduling:

• Goals are added or removed from schedule • Predicted travelling times are incorrect • Predicted task durations are incorrect

These causes are not universal: the relevance of each of them is strongly related to the specific domain of logistics. For example, depending on the goal at hand there might be few or many delays, as some tasks may have a higher chance of being cancelled when compared to others.

From these three reasons for new information we will largely ignore the the first problem of sub-optimal routing. This aspect poses a very large problem on its own which surpasses the scope of our research.

2.2 Improving accuracy of travelling information

Since travelling information is of great importance to many individuals, organisations, and govern-ments, it has been broadly researched. With cities becoming more popular, and an increasing number of people visiting these densely populated areas, this has lead to a pressure on main roads (Barros et al., 2015). For the logistic sector this means that there’s a even higher demand on accurately predicting travelling times.

The simplest way of predicting the time needed to travel from point A to B, is to divide a road into sections and to record the time needed to cross over these sections. One of the first, and more advanced, method combined information from past travelling times, weather, day of the week, and also day of the year (Oda, 1990).This method provides great results on average but lacks performance when unpredictable events, such as heavy rain, occur. Yao et al. (2015) suggested a method which uses information from GPS traced vehicles, that could then be used in addition to the previously described method. This hybrid model highly improves short term predictions.

(12)

2.3 Advantage of short term traffic predictions versus long

term

Due to the stochastic properties of travelling time, predicting them is an interesting endeavour (Binart et al., 2016). The most accurate predicting times are however done only slightly in the future. Predicting only a few minutes or hours ahead has the advantage of being able to use recent information about the state of traffic.

As part of this thesis, a mini study has been done, in which quantifying the advantage of short term predictions was achieved. For the collection of data the ”TomTom online routing API” was used. We started by collecting long term predictions about travelling time. This is done for a period of two weeks in which a set of five different routes in Amsterdam (two of which contained large parts of the city belts) were watched. In this period, data was gathered within a 15 minutes interval. This data only contained the predicted travelling time. When the selected two week period started, data was collected every 15 minutes about the actual travelling time. In this case ’actual travelling time’ is defined as the time TomTom’s real time travelling API said the trip would take.

A single data point is shown in table 2.3.

data point description seconds travelling time predicted at beginning of two weeks 1000

travelling time predicted 60 minutes in advance 1000 travelling time predicted 45 minutes in advance 1000 travelling time predicted 30 minutes in advance 1000 travelling time predicted 15 minutes in advance 1012 travelling time predicted 0 minutes in advance 1042 Figure 2.1: Overview of a data point in experiment

We used these data points to see how large the difference was between the prediction done at least 24 hours in advance and predictions done up to 90 minutes in advance. The found results are surprising: taking the average of the five selected routes a maximum difference of 10 percent was found. Incidents also happened a maximum of one time a day. Since we believe these results are not trustworthy for the purposes we need, we have discarded them.

(13)

Chapter 3

Method

The research question will be answered with a comparison of the data. In particular the comparison between simulations in which we do allow for rescheduling during the day and the situation in which we do not. In our simulation we will use known characteristics of the world as well as the knowledge described in chapter two to create an simulation which is realistic.

The parameter values we cannot know for sure have been chosen to be both realistic and humanly understandable. This approach has been chosen to ensure that the results will be approachable and understandable by a broader audience. They can compare the found output values and compare them to their own experiences in this world.

3.1 Simulation

The created simulation replicates a task where set of vehicles that have to visit a set locations. To travel to these locations they can only use the given routes/edges. These edges have a certain travelling time which can differ due to simulated traffic accidents. Each run of the simulation we will change one parameters value and make a re-run. The values that will be varied are the following:

1. Task duration

2. Number of traffic incidents 3. Severity of traffic incidents 4. Rescheduling allowed

(14)

We tested four different task durations ranging from 0 minutes to 30 minutes, four different level of intensities of traffic incidents ranging from 20 percent to 80 percent, and a set of six incident counts ranging between 0 and 500.

The setup for all of these simulations works in the following way:

1 # Set initialise seed for all simulations with same value

2 var globalseed = 3141

3

4 # Set empty simulation array

5 var simulationArray = [] 6

7 # Initialize all the different combinations

8 var parameter0 = [parameter0_Value_0, parameterA_Value_1, ..., parameterA_Value_N] 9 var parameter1 = [parameter1_Value_0, parameterA_Value_1, ..., parameterB_Value_N] 10 ....

11 var parameterN = [parameterN_Value_0, parameterA_Value_1, ..., parameterN_Value_N] 12

13 # Create a combination of all of the possible parameter values

14 Foreach parameter0 as parameter0val 15 Foreach parameter1 as parameter1val

16 ...

17 Foreach parameterN as parameterNval 18

19 # Create a basic simulation

20 var simulation = new mainSimulation() 21

22 # Set all the properties

23 simulation.parameter0 = parameter0val 24 simulation.parameter1 = parameter1val 25 ... 26 simulation.parameterN = parameterNval 27 28 simulationArray.add(simulation) 29 30

31 # Run each of the simulations or delegate them to another machine 32 Foreach simulationArray as simulation

33 simulation.run() 34 end

A global random seed is used to be able to replicate results in a future phase. The simulation start by a initialisation phase in which the vehicles, targets and routes are initialised. We then create the routes between the addresses.

After initialisation a scheduling algorithm creates a schedule at the beginning of the day. For this it only uses the estimated travelling time and assumes that every step is executed timely. This step also ensures that each address receives a estimated time of arrival, or ETA, which will be used in future steps.

When the initial schedule is created the script continues with traffic incidents. These are created with a (seeded) random placement algorithm. Incidents do affect a very small area around itself so

(15)

that incidents on small roads influence all other routes taking that road.

After setting up our environment the simulation can start. The assumption is made that vehicles cannot be rerouting while being on their way to an address. This also means that the rerouting algorithm only has to run when a vehicle is about to leave an address. In half of the simulations no rerouting is being done. A example of what the simulation looks like can be seen in image 3.1. In the following sections each of these steps are laid out in more detail alongside with a description of technical details.

Figure 3.1: Example of simulation #320 halfway through the day

3.1.1 Initialisation of Targets and Routes

As described we start with the generation of a random data set. The full data set that is created consists of 30 visitable addresses1_{. They are created using a random seed which is initialised with}

the number ”3141”. As required of our research question the random placement is limited to a frame around the city of Amsterdam.

(16)

Next we find the shortest routes between all the addresses resulting in a total of 8702_{different routes.}

For this we use the Google Maps API. One might argue for the removal of return routes. However, the return route quite often is different in both travelling time and distance. For example, the route might contain a one way road which are abundant especially in central Amsterdam.

Another argument could be made for the usage of euclidean distance3_{between points as an estimation}

of travelling time. These routes do however encode another piece of information: namely how often the same routes used. In a ring city such as Amsterdam we tend to use ring roads fairly often, you can clearly see how this piece of information is absent in image 3.2 and present in image 3.3. If we want vehicles that travel the same road to encounter the same traffic delays, this step is crucial. The choice for using real routes as opposed to euclidean distances does have a downside: the API request limit will also limit the number of simulations that we can run on a daily basis.

3.1.2 Initialisation of Vehicles

Depending on which simulation a number of vehicles is initialised. These are placed at the left border of the map rather than randomly. This is done for two reasons. The first reason is clarity: it helps with making clear when vehicles are done with their schedule. Secondly it represents a more real world situation: in most imaginable situations trucks depart from a depot or some location outside of the city centre.

3.1.3 Initialisation of Incidents

The placement, frequency and severity4 of incidents lie at the root of this research; without them there would be no purpose in rescheduling. Therefore, this topic has been given a fair amount of thought. Therefore, a small background research has been done on this topic which is described in section 2.3. However, a realistic basis upon which the severity, frequency, or placement, of incidents could be based was not found.

For the placement of incidents there is the advantage of the assumption that they are not able to divert from the previously created routes. Therefore, only the traffic on these routes needs to be simulated. The incidents are placed randomly on distinct routes. To create a realistic situation routes that have an incident also influence other routes adjacent to it, an example of this is shown in

2 _{The maximum number of addresses is 30 therefore 30 * 30 - 30 routes are possible. The deduction of 30 routes}

is since we are not interested in return roads.

3_{The distance between two points as travelled over a straight line between two points} 4_{We define severity of an incident as a factor on the total travelling time}

(17)

Figure 3.2: Example of random targets with euclidean shortest routes

(18)

image 3.4, if the route that touches already has an incident the highest severity is leading. Routes that do not touch are not effected by incidents as shown in image 3.5.Since no trustworthy data is available to base the severity and frequency the decision has been made to turn these into parameters for our simulation.

Incidents are created immediately after a schedule has been made. Therefore the schedule can not use the incident information. Furthermore, the reasonable assumption has been made that the vehicles themselves do not influence traffic.

(19)

Figure 3.4: Incident on a road close to a roundabout.

(20)

3.1.4 Scheduling Algorithm and Rerouting

The goal of the simulation is to compare rescheduling with non-scheduling situations. The initial schedule is created using the exact same algorithm as the rerouting, thereby we ensure that there is no unfair advantage between the scheduling beforehand and the scheduling when we have more information.

Rerouting is only being done at certain points in time. Since there are infinite times at which a rerouting could be started assumptions are required to make the simulation possible within a reasonable time frame. It should be noted that in a real life situation the amount of time that a rescheduling algorithm can run is potentially longer.

The first assumption is that when a vehicle is on its way towards a task it can no longer be resched-uled. This assumption is reasonable for most situations, it is unlikely that when a vehicle is already moving towards a target rescheduling it would lead to improving the schedule. A second reason for this assumption is that for the algorithm to be able to reroute halfway would need travelling times from that point towards each of the possible addresses. The second assumption is that a vehicle has perfect knowledge of the actual travelling times over each of the routes at the current point in time but has no knowledge of where future accidents might happen. The last assumption is that tasks cannot be skipped. Even in situations where there is no hope of completing the task within the time frame it still needs to be completed.

There are two differences between the first run of the algorithm and future runs. In the first run the algorithm cannot use information about what the traffic will be like. And the moment the truck is estimated to arrive will be used as the ETA for that address. Since this algorithm is only run at departure from a address it is run a maximum of 30 times per simulation.

The following pseudo code shows the steps in the creation of the original schedule as well as the updated schedule.

(21)

1 # Set variables

2 var vehiclesArray = [list of vehicles] 3 var taskArray = [list of tasks to be done] 4

5 # Calculate current position of vehicle

6 Foreach vehiclesArray as vehicle 7

8 # If vehicle is still moving towards a task

9 # get location and time when done 10 if Vehicle isMovingToTask 11 vehicle.simulateDoneTask

12 vehicle.storeLocationTimeDoneTask 13

14 # otherwise use its current position 15 else vehicle.storeCurrentLocationAndTime 16

17 # Basic algorithm

18 DivideTasks() 19 ForEach Vehicle

20 Find closest task in taskArray

21 ClaimTask()

22

23 if taskArray.length > 0 DevideTask() 24

25 # If a current schedule is already in place, check if new schedule has more optimal properties

26 # Check if new ETA score is better, then update schedule

27 if(currentSchedule.ETAscore < newSchedule.ETAscore) UpdateSchedule() 28 else KeepSchedule()

29

30 % # Advanced algorithm (not used

31 % BranchStep() 32

33 % # If no branch is created yet

34 % if(not hasBranches)

35 % Foreach vehiclesArray as vehicle 36

37 % Find top 5 closest task in taskArray 38 % Foreach taskInTop5 as taskInTop 39 % calculateArrivalTimeThisTruck() 40 % calculateDifferenceWithSetETA() 41

42 % # Start / expand branches

43 % ForEach branch()

44 % Find top 5 closest task in taskArray 45 % Foreach taskInTop5 as taskInTop 46 % calculateArrivalTimeThisTruck() 47 % calculateDifferenceWithSetETA() 48

49 % # We now have 5 branches per vehicle and a total of

50 51

52 % # Filtering of very bad combinations out of branch

53 % # to make algorithm not have to many branches in memory

54 % Foreach algorithmBranch CalculateETAMismatch() 55 % Foreach algorithmBranch FilterBest5()

56

57 % # Check if need further branching

58 % if taskArray.length > 0 BranchStep() 59 % else algorithmBranch.FindBest() 60 61 % # Init algorithm 62 % BranchStep() 63

64 % # Check if new ETA score is better, then update schedule

65 % if(newBest.ETAscore < oldBest.ETAscore) UpdateSchedule() 66 % else continue

(22)

3.2 Technical details

The steps which are described in this chapter have been converted into Javascript code which run on a Node server. For the generation of random numbers the package ”random-seed” with input value ”31413” has been used. The choice for a package rather than the native Javascript has been made because the native random generator does not allow for seeding.

The code was run on two virtual Linux instances running Node 5.1. Since the Node.JS version used can only be run on a single core, two single core 1 GB memory Ubuntu 14.04 instances were used. After running the script for three hours the results of 30 simulations were generated of each of the 192 different instances. This approximates to a duration of two to four seconds per simulation which was mostly dependant on the number of traffic accidents.

(23)

Chapter 4

Experiments and results

The described simulation is run 30 times for each of the chosen 192 scenario’s totalling 5.760 simu-lations. The different parameters, which combined make up these scenario’s, are laid out in section 2.1. Furthermore, we decided to split up the results in several subsets, thereby giving more insight in the results. How and why this is done is made explicit in section 2.2. Section 2.3 gives a showcase of the total output variables and a description of what differences are found between the scenario’s. A condensed table containing a full overview of all the results can be found in appendix A.

As an objective way of comparing how well the agents behaved the following indicators are given as output from a simulation:

1. Percentage of tasks done within time frame 2. Seconds spent on the road in normal traffic 3. Seconds spent on the road in traffic 4. Absolute difference ETA and ATA1

5. Total distance travelled

After collecting these values they are divided by the number of task, hereby ensuring that they can easily be compared. E.g. when a vehicle travels a total of 2100 seconds to accomplish 7 tasks the value being shown will be 300. This will allow for future comparisons with different numbers of vehicles and tasks.

1_{The sum of the absolute values of the difference between Estimated Time of Arrival (ETA) and Actual Time of}

(24)

4.1 Parameters

As explained in the second chapter we have selected a set of parameters of which we can either way not set the values because they are not universal or because the values were not found. There-fore, these parameters were simulated with different values, in this section we will describe these parameters and give a motivation for their values.

4.1.1 Total address visiting time

This parameter contains the time a truck will stay at the goal once arrived. For these experiments this is given a fixed value which is known at the start of the day as well as during the simulation. The values which have been tested can be found in table 4.1.1. It should be noted that the

The values ranging between 0 and 30 minutes are chosen to not make experiments take too long, but at the same time be long enough to see a potential influence of long tasks on the performance of the rescheduling algorithm.

minutes 0 10 20 30

seconds 0 600 1200 1800

reached in time frame minute tolerance 5 15 25 35

reached in time frame minutes tolerance 300 900 1500 2100

Figure 4.1: Values of address visiting time used in experiments

4.1.2 Accident count and severity

The accidents are placed randomly on roads, but will also affect roads in the directly neighbouring area.

Two aspects influence, what we could call the current state of traffic. Firstly, the amount of roads that have accidents on them. Secondly the severity of these accidents e.g. how much longer does travelling along a road take during traffic.

The number of incidents ranges between 0 and 500. The different values which have been experi-mented can be found in table 4.1.2. In the third chapter we found that between a total of 30 roads a maximum of 870 shortest roads lay. This means that in the experiment with 500 accidents we can

(25)

assume almost all roads have accidents2_{. Furthermore, we must note that in the situation with 1}

traffic accident the severity of this incident will play almost no role.

count 1 5 10 50 100 500

Figure 4.2: The number of accidents that are active at the same time

The influence of severity of accidents was tested with four different values. Since the values of 0% and 100% are not interested four values between 0 and 100 were selected. These values are shown in table 4.1.2.

delay 20% 40% 60%

80%

relative vehicle speed 80% 60% 40%

20%

Figure 4.3: Average severity of each of the accidents

4.2 Division of results

The possible different values of the parameters account for 1923 _{different simulation settings. To}

best create insight in what parameters effect which aspect of rescheduling versus non-rescheduling we have divides these results in the following four groups:

1. Low traffic: contains all experiments with 1 or 5 traffic accidents

2. Medium traffic: contains all experiments which are not in the category high or low. 3. High traffic: contains all experiments with 100 or 500

4. All traffic: contains all experiments

In appendix A a full overview of all the results can be found. In each of the following sections the data of the groups will be shown.

2 _{Due to the belt roads many of the routes in Amsterdam do in fact touch and influence their neighbours with}

their incidents, therefore 500 randomly placed incidents block out a large percentage of the 870 roads.

(26)

4.3 Results

4.3.1 Low traffic

In situations with very few disturbances we expected that there would be little to win from updating routes. If the travelling times are perfectly predicted there is nothing to win from rescheduling. In table 4.1 we can see the results of simulations with very few accidents. Our expectations do very closely match the results found. There is indeed very little difference between the situation with and without rescheduling.

Even though there seems to be a slight advantage towards rescheduling, these are not found to be significant4_.

4.3.2 Medium traffic

In the simulations with medium traffic, we expect the most benefit from rescheduling. In table 4.2 the results of these simulations are shown. The influence of the rescheduling algorithm is statistically significant in most these results. We find large differences in the time spent in a vehicle, time spent in traffic as well as the distance travelled per task.

Surprisingly the end of day is rather similar, this is most likely due to the fact that in these simula-tions, a large percentage do not encounter a single incident. The most relevant difference is found in the time in queue, where the average time drops by 31 percent. This advantage does however come at a cost: the distance that has to be travelled for each task increases as well as the total time spent in vehicle.

The strange case of almost equal ETA versus ATA is caused by the method of calculating this difference.

(27)

Low traffic results

rescheduling no rescheduling

µ σ max min µ σ max min

Reached in time frame 0.9 0.1 1.0 0.7 0.9 0.1 1.0 0.6

Time in normal traffic 73.8 4.0 77.2 66.8 73.8 3.9 77.2 67.5

Time in queue 0 0 2 0 0 0 4 0

Travelled per task 1050 69 1261 803 1033 55 1080 944

End of day 6958 3429 12128 2037 6962 3426 12128 2059

ETA versus ATA 37 48 182 2 37 48 156 2

Table 4.1: Accumulated results of simulations filtered on situations with low traffic

Medium traffic results

Reached in time frame 0.9 0.1 0.9 0.4 0.7 0.1 0.9 0.4

Time in queue 1 3 19 0 10 4 22 0

End of day 7057 3630 12555 1926 7376 3592 12308 2104

ETA versus ATA 87 55 262 16 86 52 237 16

(28)

4.3.3 High traffic

In the simulations which have high traffic, we often have situations in which almost all roads are blocked by traffic. Therefore, the rescheduling will most likely perform worse than in the case of medium, simply because no proper alternative route could be selected. In table 4.3 the accumulated results of these simulations are shown. We see no difference in the number of tasks performed within the time frame, however we do see an slight improvement in the average end of day. We must however note that this comes at a slight cost in the distance being travelled.

The influence of the rescheduling algorithm is significant in these results. There is no significant improvement in the estimated time of arrival versus the actual time of arrival.

4.3.4 All traffic

In table 4.4 we see a combination of all of the results. Due to the high number of simulations most of these differences are significant. The end of day is the only situation in which this is not the case. However, it must be noted that the differences are very small.

(29)

High traffic results

Task in time frame 0.7 0.1 0.9 0.4 0.7 0.1 1.0 0.4

Time in queue 13 9 40 0 26 24 139 0

End of day 7547 3896 13864 1919 7608 3888 14089 1962

ETA versus ATA 154 90 391 34 152 80 339 36

Table 4.3: Accumulated results of simulations filtered on situations with high traffic

All traffic results

Task in time frame 0.9 0.1 1.0 0.4 0.8 0.1 1.0 0.4

Time in queue 5 6 40 0 12 12 139 0

End of day 7188 3734 13864 1919 7315 3714 14089 1962

ETA versus ATA 92 72 391 2 80 68 339 2

(30)

Chapter 5

Conclusion, Discussion, and Future

Work

In this chapter we will describe our conclusions with respect to answering our research goal of comparing the use of a scheduling algorithm that can use real time information to one that cannot. We will then discuss the assumptions which were taken into account when doing so, and end the chapter with suggestions for future research.

5.1 Conclusion

Concluding, we see that our initial answer to the research question is that there is in fact no improvement of ETA accuracy. This might be due to our definition of ETA accuracy which penalises being too early as well as being to late. In the example without rescheduling it is not possible to arrive at a address too early. In the opposite case, however, a vehicle could start moving towards a target to find that the traffic incident it counted on was resolved half way through, thereby arriving early. We do see that the number of tasks done within a time frame is equal in the worst cases but gains a rather significant improvement when the conditions are right. We also see a similar pattern in the time spent in traffic: less time is spent in queues with rescheduling. Therefore, we can conclude that the algorithm is skillful at avoiding traffic. We also find costs associated with rescheduling. In all situations in which we rescheduled, longer routes were taken than in the case without rescheduling. Additionally, more time is spent in normal traffic.

(31)

a rescheduling algorithm could be worthwhile to reach a higher task in time frame rate.

5.2 Discussion

There are certain limitations which also act as possible future improvements. An important fact to note is that the scheduling algorithm, which is used both for the original scheduling as well as the rescheduling, is sub-optimal. Better routes can be found using more advanced scheduling algorithms. We believe this is not a large problem since we are only interested in the relative improvement. We think that a simulation is the best choice to test the effects of an implementation. But it is interesting to discuss which results might differ in a real world scenario. A current assumption is that the algorithm has perfect communication time with employees. In a real world situation, communication with employees might be problematic or would at least take time. Human problems, such as not wanting an algorithm to make decisions for you, as well as cases of ignoring the advised route, might also cause disturbances in the algorithm.

We also did not take country law into account. In some countries it is not allowed to track employees, even during work time, without proper cause. In the Netherlands, for example, it is not allowed to track employees who are on their way to or from home.

Furthermore, we assumed that tasks have very accurate beginning and ending times. This could be translated to a real world situation by making the task duration as long as the maximum possible duration, thereby ensuring that the employee will be ready to go to his next task at the end of his task duration.

Last but not least, we did not check the impact of different vehicles or employees with special skills(Patton, 2005). It might be interesting to look at the influence of special vehicles such as bicycles or motorbikes, which are less influenced by traffic.

Although it is likely that the amount of time saved will not be exactly the same in an real world implementation of the algorithm, we have shown advantages of a real time scheduling algorithm.

5.3 Future research

The positive result of this research potentially sparks a field of new research that could be done. There are four directions in which more research is necessary: comparing real world data, scalability,

(32)

creating more detailed simulations, and designing smarter rescheduling algorithms.

5.3.1 Comparing with a more advanced scheduling algorithm

For a real world implementation, adding a more advanced scheduling algorithm is a crucial next step. We have shown that a advantage can be achieved by stepping from non-rescheduling to rescheduling algorithms. However, the algorithm used is not optimal. Hartmann (2002) suggests the use of genetic algorithms that show promising results.

5.3.2 Comparing to real world data

Data which contains both the results of a situation with rescheduling and also the results without rescheduling, might be very hard to find. This data could however be extremely interesting. As described in my discussion, it is likely that there is a difference between the real world and the simulation. A qualitative study that compares the simulation with experiences of employees might highlight these.

5.3.3 Scalability

The recalculation of all possible options for a data set of up to 35 addresses, that are connected with a maximum of one road, is something a 2016 high-end personal computer can do within a second. However, in larger companies, with hundreds of employees, completing thousands of tasks would require more computing power.

There is however a better method to do this which could be explained as a ”problem first” approach. Implementing such a method, which constantly recalculates the arrival time and would only trigger a rescheduling algorithm when ETA targets are not met, will certainly prove to be more efficient. A secondary advantage would be that, ceteris paribus1_{, it is likely that larger organisations benefit}

more from rescheduling. This is due to the larger amount of rescheduling options.

5.3.4 Different assumptions

Many assumptions made in this report were made due to a very strict time limit. If the assumptions would have been made differently, the set of results would also differ largely from the currently found

(33)

results. In this subsection I list some of the assumptions mentioned in the discussion and provide interesting alternatives.

A rather influential assumption is that all vehicles are equal. In most situations this is however not the case. Tasks could require a team with a certain skill set or a certain set of materials. This would largely limit the number of rescheduling that could be done.

The assumption of a very easy cost/benefit function that is at the heart of the scheduling algorithm could also be changed. As of now it aims to get the best estimated time of arrival versus actual time of arrival score. Even though this might be a very important factor there are many others that could be added:

• Cost of employee work overtime • More, and less important, tasks • Vehicle kilometer costs

• Cost of dropping a task • Drop off / pick up locations

Specifying these costs will enable the algorithm to make choices which are more in line with the company policy. Research from 2016 has shown that in these conditions improvements could be reached (Castillo-Salazar et al., 2016).

(34)

References

Barbucha, D. (2013). A multi-agent approach to the dynamic vehicle routing problem with time windows. , 467–476.

Barros, J., Araujo, M., & Rossetti, R. J. (2015). Short-term real-time traffic prediction meth-ods: A survey. In Models and technologies for intelligent transportation systems (mt-its), 2015 international conference on (pp. 132–139).

Binart, S., Dejax, P., Gendreau, M., & Semet, F. (2016). A 2-stage method for a field service routing problem with stochastic travel and service times. Computers & Operations Research, 65 , 64–75.

Castillo-Salazar, J. A., Landa-Silva, D., & Qu, R. (2016). Workforce scheduling and routing prob-lems: literature survey and computational study. Annals of Operations Research, 239 (1), 39–67.

Hartmann, S. (2002). A self-adapting genetic algorithm for project scheduling under resource constraints. Naval Research Logistics (NRL), 49 (5), 433–448.

Liebig, T., Piatkowski, N., Bockermann, C., & Morik, K. (2016). Dynamic route planning with real-time traffic predictions. Information Systems.

Moridpour, S., Anwar, T., Sadat, M. T., & Mazloumi, E. (2015). A genetic algorithm-based support vector machine for bus travel time prediction. In Transportation information and safety (ictis), 2015 international conference on (pp. 264–270).

Oda, T. (1990). An algorithm for prediction of travel time using vehicle sensor data. In Road traffic control, 1990., third international conference on (pp. 40–44).

Papadimitriou, C. H. (1977). The euclidean travelling salesman problem is np-complete. Theoretical Computer Science, 4 (3), 237–244.

(35)

Association of Community Colleges.

Tchrakian, T. T., Basu, B., & O’Mahony, M. (2012). Real-time traffic flow forecasting using spectral analysis. Intelligent Transportation Systems, IEEE Transactions on, 13 (2), 519–526.

Van Lint, J., Hoogendoorn, S., & van Zuylen, H. J. (2005). Accurate freeway travel time prediction with state-space neural networks under missing data. Transportation Research Part C: Emerging Technologies, 13 (5), 347–369.

Yao, B., Wang, Z., Zhang, M., Hu, P., & Yan, X. (2015). Hybrid model for prediction of real-time traffic flow. In Proceedings of the institution of civil engineers-transport (Vol. 169, pp. 88–96).

Zhang, Y., & Haghani, A. (2015). A gradient boosting method to improve travel time prediction. Transportation Research Part C: Emerging Technologies, 58 , 308–324.

(36)

Appendix A

(37)

lo w traffic medium traffic high traffic all traffic r eschedul ing no... r eschedul ing no... r eschedul ing no... r eschedul ing no... Reac hed in time frame 0.9 0.9 0.9 0.7 0.7 0.7 0.9 0.8 Time in normal traffic 73.8 73.8 96.0 70.5 71.0 65.7 80.3 70.0 Time in queue 0 0 1 10 13 26 5 12 T ra v elled p er tas k 1050 1033 1269 993 1133 1045 1123 1023 End of d a y 6958 6962 7057 7376 7547 7608 7188 7315 ET A v ersus A T A 37 37 87 86 154 152 92 80 T able A.1: Res u lts in all differen t scenario’s as describ ed in chapter 3. ”No ...” stands for ”no resc heduling”

REALTIME DYNAMIC SCHEDULING