256 report

Intelligent Transportation System

FS 2010

Master Thesis

Supervised by: Author: Dr. Rudolph Triebel Kay Noyen

Martin Rufli

Prof. Dr. Roland Siegwart

Autonomous Systems Lab

Prof. Roland Siegwart

Contents

1 Introduction 3

2 Problem Formulation and Definitions 52.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Literature Review 8

4 Approach: Preliminary Work 114.1 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Vehicle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Simulation Environment . . . . . . . . . . . . . . . . . . . . . 13

5 Approach: Scheduling Algorithm 145.1 Request Conversion . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Online Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3 Request Allocation . . . . . . . . . . . . . . . . . . . . . . . . 175.4 Request Insertion . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4.1 Time Window Insertion . . . . . . . . . . . . . . . . . 185.5 Cost Calculation . . . . . . . . . . . . . . . . . . . . . . . . . 205.6 Cut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Experiments and Results 226.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.2 Online vs Oine . . . . . . . . . . . . . . . . . . . . . . . . . 25

1

6.3 Varying Cut Parameter . . . . . . . . . . . . . . . . . . . . . . 276.4 Varying Maximum Level of Service . . . . . . . . . . . . . . . 296.5 Pickup vs Dropoff Proximity . . . . . . . . . . . . . . . . . . . 316.6 Average vs Maximum Value Optimization . . . . . . . . . . . 336.7 Level of Service vs Total Travel Time Optimization . . . . . . 35

7 Conclusion 38

2

Chapter 1

Introduction

Common public transportation systems provide a cost-effective way to movemore or less freely in urban areas. A key characteristic of subway, bus, trainand tram networks is the exclusive existence of fixed stops and schedules.The static design makes passengers passively bundle their demand for trans-portation in terms of place and time. Thus it allows service providers toallocate vehicles with high capacity which ultimately results in a low priceof transportation for their customers. However for the benefit of a low priceusers have to take into account a substantial loss of flexibility. They cannotdepart from and arrive at the exact location they desire and have to complywith fixed timetables. Additionally passengers have to to travel in ratheruncomfortable and possibly insecure vehicles.

In this thesis the assumption is made that the users demands for trans-portation cannot only be bundled by constraining the demands physicalattributes, but also by processing of information about the users originaldemands. Where does the passenger want to depart? Where does he wantto go? When does he want to go? Recent development of hardware and soft-ware technology in the area of telecommunication systems lay the foundationto acquire such transportation requests in real time. Modern smart phoneswith integrated GPS device and wireless data connection are on the edge ofbecoming standard equipment of personal life. They provide a convenient

3

CHAPTER 1. INTRODUCTION 4

Figure 1.1: Outline: Intelligent Transportation System

interface to broadcast the users transportation demands using already de-veloped infrastructure.

The aim of the thesis at hand is to develop a system that is able to processdispatched transportation request into as optimal as possible routes for a setof vehicles that can handle multiple requests at once in real time. The vehiclesdo not have fixed stops and timetables. Passengers choose an earliest timeof service and are picked up exactly where they want to depart and droppedoff exactly where they want to arrive. Their complete transportation requestis handled in adjustable time window constraints.

Chapter 2

Problem Formulation andDefinitions

This thesis deals with an online variation of the "Dial-a-Ride Problem" (DARP).Transportation requests emerge over time and are not know in advance. Fig-ure 2 shows the problems basic layout. k vehicles have to serve i transporta-tion request subject to multiple objectives and constraints given below.

[ei+,li+]

[ei-,li-]

ti+,i-

t1+,1-[e1+,l1+]

[e1-,l1-]

t2+,2-

[e2+,l2+]

[e2-,l2-]

V1

V3

Vk

V2

V4

Figure 2.1: Vehicles V and Requests i

5

CHAPTER 2. PROBLEM FORMULATION AND DEFINITIONS 6

2.1 Definitions Level of Service (los): quotient of actual ride time and direct ride time

Delay of Service (dos): time from earliest time of service to actualpickup

Wait times (wait): time from arrival of vehicle till earliest pickup time

Total travel time (tot): actual drive time for a route

2.2 Objectives Serve as many demands as possible

Minimize total travel time of all vehicles

Minimize number of used vehicles

Minimize Level of Service

Minimize Delay of Service

Minimize waiting times

It is clear that it is not possible to fulfill all objectives without violatingothers. For example minimizing total travel time and the number of usedvehicles implicitly increases level of service values. Therefor

2.3 Constraints TimeWindows: Every accepted request imust be served within its time

windows [e+i , l+i ] for pick-up and [ei , li ] for drop-off. This constraintimplicitly limits the maximum drive time of a passenger.

Capacity: The load of a vehicle must never exceed its maximum loadqv qmax.

CHAPTER 2. PROBLEM FORMULATION AND DEFINITIONS 7

Precedence: At no time a drop-off i can occur before its dedicatedpick-up i+.

Chapter 3

Literature Review

This literature review is intended to provide an overview on available pub-lications covering the dynamic multi-vehicle dial-a-ride problem with timewindows. It puts earlier research achievements into context with the presentthesis and discusses their overall performance as well as their applicabilityto the outline of the thesis from a critical point of view.

Since research on the dial-a-ride problem (DARP) began in the early1970s, many variations of the DARP have evolved. Most of the availableliterature covers DARP variations which for the most part are not directlyrelevant for this thesis as they cover static and/or single-vehicle DARP. Onlyfew publications focus on the case of the multi-vehicle dynamic DARP withtime windows.

The aim of this thesis is to develop, simulate and evaluate an intelli-gent transportation system that is able to compete with customary systemsunder real-life conditions. The demand of dynamically accepting passengerrequests over time impose close constraints on the running time of appliedalgorithms. Hence robust and particularly fast algorithms are necessary forthe practical application of the DARP. However the DARP is NP-hard. Itis not possible to obtain globally optimal solutions in reasonable time thatmeet the required constraints. That is why algorithms for the multi-vehicle

8

CHAPTER 3. LITERATURE REVIEW 9

dynamic DARP presented here are heuristics.

A recent survey on DARP has been conducted by [2]. It covers static anddynamic as well as single-vehicle and multi-vehicle variations of the DARP.Not only does it give a broad overview on what has been done in the area ofdial-a-ride research, but also proposes two interesting algorithms to solve themulti-vehicle dynamic DARP. Those algorithms account for the core part ofthis literature review.

An attempt to solve the DARP using fuzzy logic was made in [4]. Twoapproximate reasoning algorithms based on fuzzy sets and simple reasoningrules are developed. As time windows are interpreted as fuzzy numbers, fuzzyarithmetic is used to insert new requests into previously generated schedulesand to check time constraints. Input data for the two approximate reasoningalgorithms is extracted from those temporary schedules. The first algorithmassigns an incoming request to a vehicle. It derives a preference strength toassign the new request to the vehicle in question by considering the extradistance traveled to serve a new passenger and the waiting time for the startof servicing of a new passenger. Once a request is assigned to a specific vehi-cle, the decision where to insert the additional passengers drop-off node intothe current schedule is made by the second algorithm. It generates a pref-erence strength by embracing additional passengers traveling distance andadditional passengers traveling time for each possible insertion point in theschedule. The first main characteristic of this approach is the introductionof fuzzy logic as a more human like way of describing periods of time anddistances as well as incorporating this in the reasoning algorithms. Secondlya main characteristic is the break down of the problem into two sub-problemsof first assigning a new request to a vehicle and then optimizing the vehiclesschedule exclusively. Naturally this way of decoupling the optimization iscommon in the literature. Since the insertion step is not trivial, it is unfor-tunate that there is no clear explanation how this task was accomplished.

In [1] a system for the optimization of DARPs is presented. The model

CHAPTER 3. LITERATURE REVIEW 10

used imposes hard and soft constraints on the scheduling of requests. Thismethod allows for generating flexible schedules, leaving the soft constraintssubject to optimization and negotiation with the passenger. Hard constraintsinclude precedence (no passenger can be dropped off before he has beenpicked up), capacity and pick-up time windows. Soft constraints includedrop-off time windows and the minimum level of service that can be guar-anteed. The level of service is defined by the ratio between the service timeoffered by the system and the hypothetical direct ride time. The objectivefunction is to minimize the worst level of service among all the customers,which implicitly approximately optimizes the distance traveled by all vehicles.The objective to maximize the number of customers is indirectly achieved bynegotiating the conditions of service with the passenger and not just refus-ing request e.g. with too small time windows. Scheduling is done by twoalternating routing and partitioning algorithms. Routing is performed by alinear programming branch-and-bound algorithm that composes its searchtree out of the feasible sequences of pick-ups and drop-offs in the schedule.Partitioning is done by a local search algorithm with limited neighborhood,which is the exchange of the passenger, who is not already on board, with thelowest level of service between different vehicles. The main characteristicsof this paper are that a full model including two case studies is describedand that the optimization problem is not fully decoupled. Interestingly theallocation of requests to vehicles and the routing within a vehicles scheduleare iteratively re optimized hand in hand. This could also be an extensionto the algorithm developed in this thesis.

In [3] an approach is made to deal with unexpected customers. Vehiclesjust pick up passenger as they occur. Although this system is not closelyrelated to the thesis at hand, it could also be an extension.

Chapter 4

Approach: Preliminary Work

To build a realistic foundation for the scheduling algorithm, several pre-liminary steps had to be taken. The following sections briefly describe theintegration of a city map, a possible model to simulate vehicles and show thesimulation environment.

4.1 MapGeometric data is taken from openstreetmap.org in XML-Format and con-verted into an optimized directed graph. The graph incorporates one waystreets and speed limits. Dijkstra shortest path algorithm is run over thegraph to produce a precomputed matrix containing direct ride times fromevery node to any other node. The exact paths between those nodes can bebacktraced. The procedure to acquire such a map is universal, so any citywhich is available on openstreetmap.org can be used. Figure 4.1 shows a mapof Zurich with its nodes and streets (edges).

11

CHAPTER 4. APPROACH: PRELIMINARY WORK 12

(a) Nodes (b) Streets

Figure 4.1: Map: Zurich

4.2 Vehicle ModelA vehicle model 4.2 was developed to simulate vehicles in the map. It is notrelevant in the later algorithm and was mainly used for test purposes. Whenthe system will be able to handle uncertainties later on, the vehicle modelwill become essential to output the status of the system (vehicle positionsetc).

Figure 4.2: Vehicle Model

CHAPTER 4. APPROACH: PRELIMINARY WORK 13

4.3 Simulation EnvironmentFigure 4.3 shows the developed simulation environment used to evaluate andtest different approaches.

Figure 4.3: Simulation Environment

Chapter 5

Approach: SchedulingAlgorithm

DARPs are extremely difficult combinatorial problems. It is not possible tosolve them exactly in reasonable time, except the problem size is very small.This is not the case for the ambition of this thesis. Therefor an insertion-based heuristic is developed.

Figure 5.1 shows the basic layout of the scheduling algorithm. A userstransportation request is converted into time windows. Before the requestis allocated to a vehicle, the status (position, load, etc) of all vehicles isupdated. A priority list of allocation is derived by calculating the proximityof a the request to all active vehicles. Then the request is consecutively triedto be inserted into the vehicles schedules according to the priority list. Assoon there is a feasible insertion, costs for all possible resulting routes arecalculated and finally only given number of best routes are maintained andthe rest is cut off. All important subroutines are explained in detail in thefollowing sections.

14

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM 15

Online Update

Request Allocation

Request Insertion

Drop Request

Feasibleno

no andno vehicles left

Cut

yes

Request Conversion

Cost Calculation

Request

Figure 5.1: System Overview

5.1 Request ConversionUsers request are converted into time windows. A user request is an earliesttime of pickup, a pickup location and a dropoff location. The parameter mpdetermines the length of the pickup window. Knowing two locations, we cansimply read the direct ride time td from pickup to dropoff from our precom-puted shortest path matrix. The earliest time of dropoff is the earliest timeof pickup plus the time for the passenger to get in or out of the vehicle tsplus td. The length of the dropoff window is determined by the parameterml.

Figure 5.3 illustrates time windows and additional important attributes,which will be essential in the scheduling algorithm. Every time window in aschedule has its arrival time (the time when the vehicle is planned to arriveat the windows location), its departure time (the time when the vehicle isplanned to depart from the windows location) and its latest arrival time (thetime, the vehicle can arrive at the windows location the latest in order to beable to arrive at all following windows in time).


Figure 5.2: Time Windows

(a) Arrival Times (b) Destination Times

(c) Route (d) Latest Arrival Times

Figure 5.3: Time Windows: Arrival, Destination and latest Arrival Times

5.2 Online UpdateIn this thesis vehicle schedules are constructed as trees. After arriving at thelocation of a window there can be multiple options to go on. How these treesare constructed exactly will be explained later on. Each of the last windowsin the the schedule represent one possible route to handle all requests in theschedule. A cost can be assigned to every route (this will be explained lateron as well). For now, when a vehicle arrives at a branching point, the branch


which includes the route with the lowest costs is chosen to go on. This iscalled "Decision Step" and shown in figure 5.4.

Figure 5.4: Decision Step

To handle the online update, the algorithm has to keep track of threeimportant time windows:

Last window: The time window which was visited the last

Next window: The time window which is to be visited next

First cost window: The time window which is the last active (passengerin the vehicle)

5.3 Request AllocationTo allocate a request to a specific vehicle first the vehicles are prioritized aseither active or not active while still being in the depot. This is done to min-imize the number of active vehicles. Then the proximity of the request to allvehicles in the first group are calculated is calculated. Proximity means theweighted euclidean distances from the requests pickup and dropoff windowsto the locations the vehicle will most likely be at the beginning of the requeststime windows. This is done to maximize the probability that shared ridesoccur. If the first group is empty, the same is done for the second group. A


priority list of vehicles with the smallest proximity to the request in questionis passed on to request insertion subroutine. It is important to note, thatwe do not know anything about the feasibility of the insertion of the requestinto the proposed schedules.

5.4 Request InsertionWhen a request is to be inserted into a schedule, both the insertions of pickupand dropoff windows have to yield a feasible schedule tree. Therefore firstthe pickup window is inserted into the schedule and only if this is feasible,the dropoff window is inserted. Figure 5.5 shows the simplified process.

Request Feasible

Feasible

Window Insertion

Window Insertion

Drop Vehicle

Drop Vehicle

OK

Pickup Window

Dropoff Window

no

no

yes

yes

Figure 5.5: Request Insertion

5.4.1 Time Window Insertion

The insertion of time windows into a schedule tree is the key part of thealgorithm. Figure 5.6 shows a the simplified process of inserting a window


into a schedule tree. The algorithm runs recursively through the alreadyscheduled windows and checks if the the window in the schedule is beforeafter or overlapping the window to be inserted. For the different cases ittakes the illustrated actions. A key characteristic of the algorithm at hand isthat feasibility can be checked fast by comparing arrival times with readilycomputed latest arrival times.

Window

Children

Befor

e

After

Overl

appin

g

Insert at end

Befor

e

After

Overl

appin

g

Insert overlappingInsert in between

Stop Get children

yesno

Start Window

Figure 5.6: Window Insertion


Insert in between: Feasibility is checked. If insertion is feasible, thenew window is inserted in between the window in the schedule and theone before. Algorithm marks the branch as feasible and stops lookingin this branch, because no later insertion is possible. All subsequentarrival and departure times are updated. Branches containing latestarrival time violations are deleted.

Insert overlapping: Feasibility is checked. If insertion is feasible, thenew window is inserted after the window before the window in theschedule and a copy of the window in the schedule and all its sub-sequent windows is attached to it. Algorithm marks the branch asfeasible and continues looking in this branch, because later insertionis possible. All subsequent arrival and departure times are updated.Branches containing latest arrival time violations are deleted.

Insert at end: There is no window after the new window in the schedule.Feasibility is checked. If insertion is feasible the window is inserted afterthe window in the schedule

It is important to note, that the above description of the window insertionprocess is heavily simplified. In the recursive structure of the algorithm alsoprecedence constraints have to be checked, maximum latest arrival times foreach window have to be set and the latest and next window for the onlineupdate have to be altered in some situations.

5.5 Cost CalculationWhen calculating the costs for a possible route, all quality measures for eachpassengers are gathered. From each set of those values the average and themaximum is used to calculate the cost in the following formula.

G(R) = ka (wl losav + wd dosav + ww waitav + wt totav) + km (wl losmax + wd dosmax + ww waitmax + wt totmax)

Figure 5.7 illsutrates the cost function G(R) for several possible routesR.


Figure 5.7: Cost Calculation

5.6 CutThe main advantag of the algorithm presented in this thesis is its adapt-ability to the complexness of the problem. Regarding one vehicle all possiblecombinations of time windows to construct feasible routes can be accountedfor and maintained in the system, as it moves on. But as computation timegrows exponentially with the number of inserted time windows, there is abuild in possibility to cut the away "bad" routes. The parameter c denotesthe number of "best" routes that have to be left. This way computation timecan be held at a certain level, enabling the algorithm to handle even largeproblem sizes.

Chapter 6

Experiments and Results

6.1 SetupIn order to study the systems characteristics, gain some knowledge about itscapabilities and to test its performance several experiments were conducted.Each of these experiments involves a different set of system parameters. Mul-tiple sets of randomly generated transportation requests are injected into thesystem for each set of system parameters. The system parameters are alteredand again the same requests are injected into the system to see how selectedquality and performance values change.

Figure 6.1 shows the basic setup for the experiments as well as all tunablesystem parameters. A list of them and a short description of how theyinfluence the systems behavior is given below.

ml: This parameter controls how far away from the pickup window andhow long the dropoff window is. For a value of 1 the time between theearliest pickup and the latest dropoff is the direct ride time.

mp: Length of pickup window

pp: Weight of the proximity of a location in a vehicles schedule to thepickup location of a request in the preference to assign the request tothe vehicle

22

CHAPTER 6. EXPERIMENTS AND RESULTS 23

Online Update

Request Allocation

Request Insertion

Drop Request

Feasibleno


Cut

yes

pppd

wl, wd, ww, wt ka, km

c

Request Conversion mlmp

Cost Calculation

Request Generation

Figure 6.1: Experimental Setup

pd: Weight of the proximity of a location in a vehicles schedule to thedropoff location of a request in the preference to assign the request tothe vehicle

wl: Weight of level of service values in the objective function

wd: Weight of delay of service values in the objective function

ww: Weight of vehicle wait time values in the objective function

wt: Weight of total travel time values in the objective function

ka: Weight of average values in the objective function

km: Weight of maximum values in the objective function

c: Determines how many routes are left when cutting back a scheduletree

All result graphs show the mean value of the multiple experiments carriedout. Error bars indicate one standard deviation. All parameters and values


for the setup of the experiments can be found in table 6.2. They apply to allexperiments except stated otherwise.

Parameter ValueMap Zurich, inner cityNumber of sets of requests 25Number of requests 100ml 3mp 2 minpp 0.5pd 0.5wl 0.25wd 0.25ww 0.25wt 0.25ka 0.5km 0.5c 3

Figure 6.2: Standard values used in all experiments


6.2 Online vs Oine

Online Update

Request Allocation

Request Insertion

Drop Request

Feasibleno


Cut

yes

Request Conversion

Cost Calculation

Request Generation

Figure 6.3: Online vs Oine Experimental Setup

In this experiment the online and oine versions of the scheduling algo-rithm are compared. Figure 6.3 shows the setup of the experiment. In theonline version requests are triggered while vehicles are already on their way.In the oine version all requests are known in advance. Yet the trigger orderof the requests remains the same.

The oine version in figure 6.4 shows slightly improved values for levelof service and delay of service compared to the online version. Number ofused vehicles and total travel time remain about the same. This slightly im-proved behavior is to be expected, since the oine version has the advantageof having access to all requests beforehand.

A significant difference can be seen when comparing the computationtimes in figure 6.5. The oine version needs more than double the compu-tation time compared to the onlline version. That is due to the fact thatthe online version saves great amounts of computation time by eliminating


1 20

0.2

0.4

0.6

0.8

1

1.2

1.4

1: Online, 2: Offline

Leve

l of S

ervic

e

(a) Level of Service

1 20

10

20

30

40

50

60

70

80

90


Del

ay o

f Ser

vice

[s]

(b) Delay of Service

1 20

1

2

3

4

5

6

7

8

9


Tota

l Tra

vel T

ime

[h]

(c) Total Travel Time

1 20

1

2

3

4

5

6

7


Num

ber o

f use

d Ve

hicle

s

(d) Number of used Vehicles

Figure 6.4: Online vs Oine Results

1 20

10

20

30

40

50

60


Com

puta

tion

Tim

e [s]

Figure 6.5: Online vs Oine Computation Time

possible routes in the schedule trees by moving the vehicles.


6.3 Varying Cut ParameterBy varying the cut parameter c from 1 to 8, the effects of cutting down sched-ule trees more or less after each insertion of a request are analyzed. A cutparameter of 1 means that after each insertion of a request the schedule treesare cut down to hold only one route. This experiment is carried out usingthe oine version of the algorithm, to make sure the effects of cancellationof routes in the results are only due to cutting of schedule trees and not dueto cancellations through moving vehicles. Figure 6.6 shows the setup of theexperiment.

Request Allocation

Request Insertion

Drop Request

Feasibleno


Cut

yes

c

Request Conversion

Cost Calculation

Request Generation

Figure 6.6: Varying Cut Parameter Results Experimental Setup

The results in figure 6.7 show that there is only small and not just desir-able change in the quality measures level of service and delay of service. Alsototal travel time and the number of used vehicles do not change significantlywith a higher cut parameter c whereas the the computation time in 6.8 in-creases drastically. Surprisingly the computation time only grows linearlyand not exponentially. This phenomenon has to rely on a unfavorable setupfor this experiment.


1 2 3 4 5 6 7 81

1.1

1.2

1.3

1.4

1.5

1.6

Cut parameter c

Leve

l of S

ervic

e


1 2 3 4 5 6 7 80

20

40

60

80

100

120

140

160

180

200

Cut parameter c

Del

ay o

f Ser

vice

[s]


1 2 3 4 5 6 7 87

7.1

7.2

7.3

7.4

7.5

7.6

7.7

7.8

7.9

8

Cut parameter c

Tota

l Tra

vel T

ime

[h]


1 2 3 4 5 6 7 80

1

2

3

4

5

6

7

8

9

10

Cut parameter c

Num

ber o

f use

d Ve

hicle

s


Figure 6.7: Varying Cut Parameter Results


1 2 3 4 5 6 7 80

50

100

150

Cut parameter c

Com

puta

tion

Tim

e [s]

Figure 6.8: Varying Cut Parameter Computation Time

6.4 Varying Maximum Level of ServiceThe idea of this experiment is to compare the developed intelligent trans-portation system to a usual taxi service. Setting the maximum allowed levelof service to 1, makes our system work exactly like a taxi service. The actualtime spend in the vehicle equals the direct ride time. Vehicles pick passengersup, bring them to their desired dropoff location and continue with the nextclosest request. Shared rides are not possible. By increasing the maximumlevel of service we can continuously transfer this taxi system into our intelli-gent transportation system and observe how quality measures change. Thesetup of this experiment is shown in figure 6.9.

Figure 6.10 shows the results for this experiment. Not surprisingly theaverage level of service values increase as the maximum allowed level of ser-vice grows. At this point it is rather essential that by relaxing the maximumallowed level of service, the total travel time and the number of used vehiclesdecrease. This was the original idea of this thesis and now is well documentedwith the given results. For example setting the maximum allowed level ofservice ml = 4 leads to an average level of service under 1.6 and an aver-age delay of service of about 2 minutes. Therefore total travel time can bereduced by over 10% and the number of used vehicles is reduced by over 40%.

Figure 6.11 shows that computation time grows exponentially with the


Online Update

Request Allocation

Request Insertion

Drop Request

Feasibleno


Cut

yes

Request Conversion ml

Cost Calculation

Request Generation

Figure 6.9: Varying Maximum Level of Service Experimental Setup

system shifting from a usual taxi service without shared rides to a highlycomplex intelligent transportation system.


1 2 3 4 5 61

1.2

1.4

1.6

1.8

2

2.2

2.4

2.6

2.8

3

Maximum Allowed Level of Service

Leve

l of S

ervic

e


1 2 3 4 5 60

50

100

150

200

250


Del

ay o

f Ser

vice

[s]


1 2 3 4 5 66

6.5

7

7.5

8

8.5

9

9.5

10


Tota

l Tra

vel T

ime

[h]


1 2 3 4 5 60

1

2

3

4

5

6

7

8

9

10

11


Num

ber o

f use

d Ve

hicle

s


Figure 6.10: Varying Maximum Level of Service Results

1 2 3 4 5 60

50

100

150


Com

puta

tion

Tim

e [s]

Figure 6.11: Varying Maximum Level of Service Computation Time

6.5 Pickup vs Dropoff ProximityFigure 6.12 shows the setup of an experiment to analyze the systems reac-tion to varying weights for pickup/dropoff proximity. This is particularlyinteresting, because it influences the request allocation, which is decoupled


from the rest of the system. Improvements made here could be integratedinexpensively in terms of computation time.

Online Update

Request Allocation

Request Insertion

Drop Request

Feasibleno


Cut

yes

pppd

Request Conversion

Cost Calculation

Request Generation

Figure 6.12: Pickup vs Dropoff Proximity Experimental Setup

The results in figure 6.14 indicate that there are some interesting balanc-ing possibilities. Level of service and total travel time occur to be inverselyproportional to each other. Giving more weight to the pickup proximityleads to lower level of service (which is desirable), but higher total traveltime (which is undesirable). More weight for the dropoff proximity leads tohigher level of service, but lower total travel time.

Computation times in 6.14 do not show significant changes.


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 11

1.05

1.1

1.15

1.2

1.25

1.3

1.35

1.4

1.45

1.5

pp = 1pd

Leve

l of S

ervic

e


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

20

40

60

80

100

120

140

pp = 1pd

Del

ay o

f Ser

vice

[s]


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 17

7.2

7.4

7.6

7.8

8

8.2

8.4

8.6

8.8

9

pp = 1pd

Tota

l Tra

vel T

ime

[h]


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

1

2

3

4

5

6

7

8

9

10

pp = 1pd

Num

ber o

f use

d Ve

hicle

s


Figure 6.13: Pickup vs Dropoff Proximity Results

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

5

10

15

20

25

30

35

40

pp = 1pd

Com

puta

tion

Tim

e [s]

Figure 6.14: Pickup vs Dropoff Proximity Computation Time

6.6 Average vs Maximum Value OptimizationThe objective function for one route includes the average quality measurevalues and the maximum quality measure values. By choosing the weightska and km we can decide if we want to minimize the average values or the


maximum values. Simply put we can choose if we want to optimize morefor the average passenger or the worst case passenger. Figure 6.15 shows theexperiments setup.

Online Update

Request Allocation

Request Insertion

Drop Request

Feasibleno


Cut

yes

ka, km

Request Conversion

Cost Calculation

Request Generation

Figure 6.15: Average vs Maximum Value Optimization Experimental Setup

Results in figure 6.16 show that optimizing just the average values ka = 1,km = 0 lead to a small decrease in level of service and total travel time anda small increase of delay of service.



0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 11

1.05

1.1

1.15

1.2

1.25

1.3

1.35

1.4

1.45

1.5

ka = 1km

Leve

l of S

ervic

e


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

20

40

60

80

100

120

140

ka = 1km

Del

ay o

f Ser

vice

[s]


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 17

7.2

7.4

7.6

7.8

8

8.2

8.4

8.6

8.8

9

ka = 1km

Tota

l Tra

vel T

ime

[h]


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

1

2

3

4

5

6

7

8

9

10

ka = 1km

Num

ber o

f use

d Ve

hicle

s


Figure 6.16: Average vs Maximum Value Optimization Results

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

5

10

15

20

25

30

35

40

ka = 1km

Com

puta

tion

Tim

e [s]

Figure 6.17: Average vs Maximum Value Optimization Computation Time

6.7 Level of Service vs Total Travel Time Op-timization

Figure 6.18 shows the setup for an experiment where we can gradually choose,if we want to optimize more for level of service or more for total travel time.


wd and ww are both 0. We expect inversely proportional results.

Online Update

Request Allocation

Request Insertion

Drop Request

Feasibleno


Cut

yes

wl, wd, ww, wt

Request Conversion

Cost Calculation

Request Generation

Figure 6.18: Level of Service vs Total Travel Time Optimization Experimen-tal Setup

Results in 6.19 consequently show that optimizing for level of serve leadsto lower level of service and higher total travel time values and optimizingfor total travel time leads to higher level of service and lower total traveltime values. Delay of service values behave inversely proportional to level ofservice values too. Interestingly the number of used vehicles does not changein this experiment.



0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 11

1.05

1.1

1.15

1.2

1.25

1.3

1.35

1.4

1.45

1.5

wl = 1wt

Leve

l of S

ervic

e


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

20

40

60

80

100

120

140

wl = 1wt

Del

ay o

f Ser

vice

[s]


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 17

7.2

7.4

7.6

7.8

8

8.2

8.4

8.6

8.8

9

wl = 1wt

Tota

l Tra

vel T

ime

[h]


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

1

2

3

4

5

6

7

8

9

10

wl = 1wt

Num

ber o

f use

d Ve

hicle

s


Figure 6.19: Level of Service vs Total Travel Time Optimization Results

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

5

10

15

20

25

30

wl = 1wt

Com

puta

tion

Tim

e [s]

Figure 6.20: Level of Service vs Total Travel Time Optimization Computa-tion Time

Chapter 7

Conclusion

The results conducted in this thesis show that from a theoretical point of viewit is possible and meaningful to use the presented intelligent transportationsystem. Computation times are reasonable even for large data sets as theyoccur in urban areas and the experiments made indicate high potential tofurther improve the quality of the system by tuning its parameters.

Standard parameters already produce usable results as pointed out in 6.4.For example according to the results a service provider using the presentedsystem only needs a little more than half of the vehicles a taxi service wouldneed to serve the same requests. This advantage for the provider can betransfered to a price reduction for the passenger, who in return has to bewilling to spend in average 1.6 times the time in the vehicle compared to ataxi.

To really implement the proposed system it is necessary to incorporateuncertainties. The system has to be prepared for passengers that do not showup, traffic jams or vehicle breakdowns to function in a real life environment.

38

Bibliography

[1] Alberto Colorni and Giovanni Righini. Modeling and optimizing dynamicdial-a-ride problems. International Transactions in Operational Research,8(2):155166, 2001.

[2] Jean-Franois Cordeau and Gilbert Laporte. The dial-a-ride problem:models and algorithms. Annals of Operations Research, 153(1):2946,September 2007.

[3] Luca Coslovich, Raffaele Pesenti, and Walter Ukovich. A two-phase inser-tion technique of unexpected customers for a dynamic dial-a-ride prob-lem. European Journal of Operational Research, 175(3):1605 1615, 2006.

[4] Dusan Teodorovic and Gordana Radivojevic. A fuzzy logic approach todynamic dial-a-ride problem. Fuzzy Sets and Systems, 116(1):23 33,2000.

39

256 report

Documents

users transportation

transportation requests

low priceof transportation

real time

time window insertion

request insertion

online vs oine

master thesis