Intelligent Transportation System: Master Thesis

Autonomous Systems Lab
Prof. Roland Siegwart
Master Thesis
Intelligent Transportation System
FS 2010
Supervised by:
Dr. Rudolph Triebel
Martin Rufli
Prof. Dr. Roland Siegwart
Author:
Kay Noyen
Contents
1 Introduction
2 Problem Formulation and Definitions

2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
6
6
6
3 Literature Review
4 Approach: Preliminary Work

11
4.1 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Vehicle Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Simulation Environment . . . . . . . . . . . . . . . . . . . . . 13
5 Approach: Scheduling Algorithm
5.1 Request Conversion . . . . . . . .
5.2 Online Update . . . . . . . . . . .
5.3 Request Allocation . . . . . . . .
5.4 Request Insertion . . . . . . . . .
5.4.1 Time Window Insertion .
5.5 Cost Calculation . . . . . . . . .
5.6 Cut . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
15
16
17
18
18
20
21
6 Experiments and Results

22
6.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Online vs Offline . . . . . . . . . . . . . . . . . . . . . . . . . 25
1
6.3
6.4
6.5
6.6
6.7
Varying Cut Parameter . . . . . . . . . . . . . . . .

Varying Maximum Level of Service . . . . . . . . .
Pickup vs Dropoff Proximity . . . . . . . . . . . . .
Average vs Maximum Value Optimization . . . . .
Level of Service vs Total Travel Time Optimization
7 Conclusion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
29
31
33
35
38
Chapter 1
Introduction
Common public transportation systems provide a cost-effective way to move
more or less freely in urban areas. A key characteristic of subway, bus, train
and tram networks is the exclusive existence of fixed stops and schedules.
The static design makes passengers passively bundle their demand for transportation in terms of place and time. Thus it allows service providers to
allocate vehicles with high capacity which ultimately results in a low price
of transportation for their customers. However for the benefit of a low price
users have to take into account a substantial loss of flexibility. They cannot
depart from and arrive at the exact location they desire and have to comply
with fixed timetables. Additionally passengers have to to travel in rather
uncomfortable and possibly insecure vehicles.
In this thesis the assumption is made that the users demands for transportation cannot only be bundled by constraining the demands physical
attributes, but also by processing of information about the users original
demands. Where does the passenger want to depart? Where does he want
to go? When does he want to go? Recent development of hardware and software technology in the area of telecommunication systems lay the foundation
to acquire such transportation requests in real time. Modern smart phones
with integrated GPS device and wireless data connection are on the edge of
becoming standard equipment of personal life. They provide a convenient
CHAPTER 1. INTRODUCTION
Figure 1.1: Outline: Intelligent Transportation System
interface to broadcast the users transportation demands using already developed infrastructure.
The aim of the thesis at hand is to develop a system that is able to process
dispatched transportation request into as optimal as possible routes for a set
of vehicles that can handle multiple requests at once in real time. The vehicles
do not have fixed stops and timetables. Passengers choose an earliest time
of service and are picked up exactly where they want to depart and dropped
off exactly where they want to arrive. Their complete transportation request
is handled in adjustable time window constraints.
Chapter 2
Problem Formulation and
Definitions
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. Figure 2 shows the problems basic layout. k vehicles have to serve i transportation request subject to multiple objectives and constraints given below.
[e2+,l2+]
[ei-,li-]
V1
-
t 2+ ,2
V3
[e2-,l2-]
i-
t i+ ,
V2
[ei+,li+]
[e1+,l1+]
Vk
t1 +,1-
V4
[e1-,l1-]
Figure 2.1: Vehicles V and Requests i
CHAPTER 2. PROBLEM FORMULATION AND DEFINITIONS
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 actual
pickup
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 violating
others. For example minimizing total travel time and the number of used
vehicles implicitly increases level of service values. Therefor
2.3
Constraints
Time Windows: Every accepted request i must be served within its time

+
windows [e+
i , li ] for pick-up and [ei , li ] for drop-off. This constraint
implicitly limits the maximum drive time of a passenger.
Capacity: The load of a vehicle must never exceed its maximum load
qv qmax .
CHAPTER 2. PROBLEM FORMULATION AND DEFINITIONS
Precedence: At no time a drop-off i can occur before its dedicated

pick-up i+ .
Chapter 3
Literature Review
This literature review is intended to provide an overview on available publications covering the dynamic multi-vehicle dial-a-ride problem with time
windows. It puts earlier research achievements into context with the present
thesis and discusses their overall performance as well as their applicability
to the outline of the thesis from a critical point of view.
Since research on the dial-a-ride problem (DARP) began in the early
1970s, many variations of the DARP have evolved. Most of the available
literature covers DARP variations which for the most part are not directly
relevant for this thesis as they cover static and/or single-vehicle DARP. Only
few publications focus on the case of the multi-vehicle dynamic DARP with
time windows.
The aim of this thesis is to develop, simulate and evaluate an intelligent transportation system that is able to compete with customary systems
under real-life conditions. The demand of dynamically accepting passenger
requests over time impose close constraints on the running time of applied
algorithms. Hence robust and particularly fast algorithms are necessary for
the practical application of the DARP. However the DARP is NP-hard. It
is not possible to obtain globally optimal solutions in reasonable time that
meet the required constraints. That is why algorithms for the multi-vehicle
CHAPTER 3. LITERATURE REVIEW
dynamic DARP presented here are heuristics.

A recent survey on DARP has been conducted by [2]. It covers static and
dynamic 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 of
dial-a-ride research, but also proposes two interesting algorithms to solve the
multi-vehicle dynamic DARP. Those algorithms account for the core part of
this literature review.
An attempt to solve the DARP using fuzzy logic was made in [4]. Two
approximate reasoning algorithms based on fuzzy sets and simple reasoning
rules are developed. As time windows are interpreted as fuzzy numbers, fuzzy
arithmetic is used to insert new requests into previously generated schedules
and to check time constraints. Input data for the two approximate reasoning
algorithms is extracted from those temporary schedules. The first algorithm
assigns an incoming request to a vehicle. It derives a preference strength to
assign the new request to the vehicle in question by considering the extra
distance traveled to serve a new passenger and the waiting time for the start
of servicing of a new passenger. Once a request is assigned to a specific vehicle, the decision where to insert the additional passengers drop-off node into
the current schedule is made by the second algorithm. It generates a preference strength by embracing additional passengers traveling distance and
additional passengers traveling time for each possible insertion point in the
schedule. The first main characteristic of this approach is the introduction
of fuzzy logic as a more human like way of describing periods of time and
distances as well as incorporating this in the reasoning algorithms. Secondly
a main characteristic is the break down of the problem into two sub-problems
of first assigning a new request to a vehicle and then optimizing the vehicles
schedule exclusively. Naturally this way of decoupling the optimization is
common in the literature. Since the insertion step is not trivial, it is unfortunate 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. This
method allows for generating flexible schedules, leaving the soft constraints
subject to optimization and negotiation with the passenger. Hard constraints
include precedence (no passenger can be dropped off before he has been
picked up), capacity and pick-up time windows. Soft constraints include
drop-off time windows and the minimum level of service that can be guaranteed. The level of service is defined by the ratio between the service time
offered by the system and the hypothetical direct ride time. The objective
function 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 by
negotiating the conditions of service with the passenger and not just refusing request e.g. with too small time windows. Scheduling is done by two
alternating routing and partitioning algorithms. Routing is performed by a
linear programming branch-and-bound algorithm that composes its search
tree 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 the
lowest level of service between different vehicles. The main characteristics
of this paper are that a full model including two case studies is described
and that the optimization problem is not fully decoupled. Interestingly the
allocation of requests to vehicles and the routing within a vehicles schedule
are iteratively re optimized hand in hand. This could also be an extension
to the algorithm developed in this thesis.
In [3] an approach is made to deal with unexpected customers. Vehicles
just pick up passenger as they occur. Although this system is not closely
related 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 preliminary steps had to be taken. The following sections briefly describe the
integration of a city map, a possible model to simulate vehicles and show the
simulation environment.
4.1
Map
Geometric data is taken from openstreetmap.org in XML-Format and converted into an optimized directed graph. The graph incorporates one way
streets and speed limits. Dijkstra shortest path algorithm is run over the
graph to produce a precomputed matrix containing direct ride times from
every node to any other node. The exact paths between those nodes can be
backtraced. The procedure to acquire such a map is universal, so any city
which is available on openstreetmap.org can be used. Figure 4.1 shows a map
of Zurich with its nodes and streets (edges).
11
CHAPTER 4. APPROACH: PRELIMINARY WORK
(a) Nodes
12
(b) Streets
Figure 4.1: Map: Zurich
4.2
Vehicle Model
A vehicle model 4.2 was developed to simulate vehicles in the map. It is not
relevant in the later algorithm and was mainly used for test purposes. When
the system will be able to handle uncertainties later on, the vehicle model
will become essential to output the status of the system (vehicle positions
etc).
Figure 4.2: Vehicle Model
CHAPTER 4. APPROACH: PRELIMINARY WORK
4.3
13
Simulation Environment
Figure 4.3 shows the developed simulation environment used to evaluate and
test different approaches.
Figure 4.3: Simulation Environment
Chapter 5
Approach: Scheduling
Algorithm
DARPs are extremely difficult combinatorial problems. It is not possible to
solve 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 insertionbased heuristic is developed.
Figure 5.1 shows the basic layout of the scheduling algorithm. A users
transportation request is converted into time windows. Before the request
is allocated to a vehicle, the status (position, load, etc) of all vehicles is
updated. A priority list of allocation is derived by calculating the proximity
of a the request to all active vehicles. Then the request is consecutively tried
to be inserted into the vehicles schedules according to the priority list. As
soon there is a feasible insertion, costs for all possible resulting routes are
calculated and finally only given number of best routes are maintained and
the rest is cut off. All important subroutines are explained in detail in the
following sections.
14
CHAPTER 5. APPROACH: SCHEDULING ALGORITHM
15
Request
Request Conversion
Online Update
Request Allocation
Request Insertion
no
Feasible
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
Figure 5.1: System Overview
5.1
Request Conversion
Users request are converted into time windows. A user request is an earliest
time of pickup, a pickup location and a dropoff location. The parameter mp
determines the length of the pickup window. Knowing two locations, we can
simply read the direct ride time td from pickup to dropoff from our precomputed shortest path matrix. The earliest time of dropoff is the earliest time
of pickup plus the time for the passenger to get in or out of the vehicle ts
plus td . The length of the dropoff window is determined by the parameter ml .
Figure 5.3 illustrates time windows and additional important attributes,
which will be essential in the scheduling algorithm. Every time window in a
schedule has its arrival time (the time when the vehicle is planned to arrive
at the windows location), its departure time (the time when the vehicle is
planned to depart from the windows location) and its latest arrival time (the
time, the vehicle can arrive at the windows location the latest in order to be
able to arrive at all following windows in time).
16
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 Update
In this thesis vehicle schedules are constructed as trees. After arriving at the
location of a window there can be multiple options to go on. How these trees
are constructed exactly will be explained later on. Each of the last windows
in the the schedule represent one possible route to handle all requests in the
schedule. A cost can be assigned to every route (this will be explained later
on as well). For now, when a vehicle arrives at a branching point, the branch
17
which includes the route with the lowest costs is chosen to go on. This is
called "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 three
important 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 (passenger
in the vehicle)
5.3
Request Allocation
To allocate a request to a specific vehicle first the vehicles are prioritized as

either active or not active while still being in the depot. This is done to minimize the number of active vehicles. Then the proximity of the request to all
vehicles in the first group are calculated is calculated. Proximity means the
weighted euclidean distances from the requests pickup and dropoff windows
to the locations the vehicle will most likely be at the beginning of the requests
time windows. This is done to maximize the probability that shared rides
occur. If the first group is empty, the same is done for the second group. A
18
priority list of vehicles with the smallest proximity to the request in question
is passed on to request insertion subroutine. It is important to note, that
we do not know anything about the feasibility of the insertion of the request
into the proposed schedules.
5.4
Request Insertion
When a request is to be inserted into a schedule, both the insertions of pickup

and dropoff windows have to yield a feasible schedule tree. Therefore first
the 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.
Pickup Window
Request
Window Insertion
Feasible
no
Drop Vehicle
yes
Dropoff Window
Window Insertion
yes
no
Feasible
Drop Vehicle
OK
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 the
algorithm. Figure 5.6 shows a the simplified process of inserting a window
19
into a schedule tree. The algorithm runs recursively through the already
scheduled windows and checks if the the window in the schedule is before
after or overlapping the window to be inserted. For the different cases it
takes the illustrated actions. A key characteristic of the algorithm at hand is
that feasibility can be checked fast by comparing arrival times with readily
computed latest arrival times.
Start Window
Window
Insert at end
Overlapping
After
yes
Before
Children
After
Overlapping
Before
no
Insert overlapping
Insert in between
Stop
Get children
Figure 5.6: Window Insertion
20
Insert in between: Feasibility is checked. If insertion is feasible, the

new window is inserted in between the window in the schedule and the
one before. Algorithm marks the branch as feasible and stops looking
in this branch, because no later insertion is possible. All subsequent
arrival and departure times are updated. Branches containing latest
arrival time violations are deleted.
Insert overlapping: Feasibility is checked. If insertion is feasible, the
new window is inserted after the window before the window in the
schedule and a copy of the window in the schedule and all its subsequent windows is attached to it. Algorithm marks the branch as
feasible and continues looking in this branch, because later insertion
is 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 after
the window in the schedule
It is important to note, that the above description of the window insertion
process is heavily simplified. In the recursive structure of the algorithm also
precedence constraints have to be checked, maximum latest arrival times for
each window have to be set and the latest and next window for the online
update have to be altered in some situations.
5.5
Cost Calculation
When calculating the costs for a possible route, all quality measures for each
passengers are gathered. From each set of those values the average and the
maximum 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 routes
R.
21
Figure 5.7: Cost Calculation
5.6
Cut
The main advantag of the algorithm presented in this thesis is its adaptability to the complexness of the problem. Regarding one vehicle all possible
combinations of time windows to construct feasible routes can be accounted
for and maintained in the system, as it moves on. But as computation time
grows exponentially with the number of inserted time windows, there is a
build in possibility to cut the away "bad" routes. The parameter c denotes
the number of "best" routes that have to be left. This way computation time
can be held at a certain level, enabling the algorithm to handle even large
problem sizes.
Chapter 6
Experiments and Results
6.1
Setup
In order to study the systems characteristics, gain some knowledge about its
capabilities and to test its performance several experiments were conducted.
Each of these experiments involves a different set of system parameters. Multiple sets of randomly generated transportation requests are injected into the
system for each set of system parameters. The system parameters are altered
and again the same requests are injected into the system to see how selected
quality and performance values change.
Figure 6.1 shows the basic setup for the experiments as well as all tunable
system parameters. A list of them and a short description of how they
influence the systems behavior is given below.
ml : This parameter controls how far away from the pickup window and
how long the dropoff window is. For a value of 1 the time between the
earliest 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 the
pickup location of a request in the preference to assign the request to
the vehicle
22
23
CHAPTER 6. EXPERIMENTS AND RESULTS

Request Generation
Request Conversion
ml
mp
Request Allocation
pp
pd
Online Update
Request Insertion
no
Feasible
wl, w d, w w, w t
ka, km
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
Figure 6.1: Experimental Setup

pd : Weight of the proximity of a location in a vehicles schedule to the
dropoff location of a request in the preference to assign the request to
the 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 schedule
tree
All result graphs show the mean value of the multiple experiments carried
out. Error bars indicate one standard deviation. All parameters and values
24
for the setup of the experiments can be found in table 6.2. They apply to all
experiments except stated otherwise.
Parameter
Map
Number of sets of requests
Number of requests
ml
mp
pp
pd
wl
wd
ww
wt
ka
km
c
Value
Zurich, inner city
25
100
3
2 min
0.5
0.5
0.25
0.25
0.25
0.25
0.5
0.5
3
Figure 6.2: Standard values used in all experiments
25
6.2
Online vs Offline
Request Generation
Request Conversion
Online Update
Request Allocation
Request Insertion
no
Feasible
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
Figure 6.3: Online vs Offline Experimental Setup

In this experiment the online and offline versions of the scheduling algorithm are compared. Figure 6.3 shows the setup of the experiment. In the
online version requests are triggered while vehicles are already on their way.
In the offline version all requests are known in advance. Yet the trigger order
of the requests remains the same.
The offline version in figure 6.4 shows slightly improved values for level
of service and delay of service compared to the online version. Number of
used vehicles and total travel time remain about the same. This slightly improved behavior is to be expected, since the offline version has the advantage
of having access to all requests beforehand.
A significant difference can be seen when comparing the computation
times in figure 6.5. The offline version needs more than double the computation time compared to the onlline version. That is due to the fact that
the online version saves great amounts of computation time by eliminating
26
1.4
90
80
1.2
70
Delay of Service [s]
Level of Service
0.8
0.6
60
50
40
30
0.4
20
0.2
10
1: Online, 2: Offline
2
(a) Level of Service
(b) Delay of Service
Number of used Vehicles
Total Travel Time [h]
7
6
5
4
3
2
1
1
0
2
2
(c) Total Travel Time
(d) Number of used Vehicles
Figure 6.4: Online vs Offline Results

60
Computation Time [s]
50
40
30
20
10
2
Figure 6.5: Online vs Offline Computation Time

possible routes in the schedule trees by moving the vehicles.
27
6.3
Varying Cut Parameter
By varying the cut parameter c from 1 to 8, the effects of cutting down schedule trees more or less after each insertion of a request are analyzed. A cut
parameter of 1 means that after each insertion of a request the schedule trees
are cut down to hold only one route. This experiment is carried out using
the offline version of the algorithm, to make sure the effects of cancellation
of routes in the results are only due to cutting of schedule trees and not due
to cancellations through moving vehicles. Figure 6.6 shows the setup of the
experiment.
Request Generation
Request Conversion
Request Allocation
Request Insertion
no
Feasible
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
Figure 6.6: Varying Cut Parameter Results Experimental Setup

The results in figure 6.7 show that there is only small and not just desirable change in the quality measures level of service and delay of service. Also
total travel time and the number of used vehicles do not change significantly
with a higher cut parameter c whereas the the computation time in 6.8 increases drastically. Surprisingly the computation time only grows linearly
and not exponentially. This phenomenon has to rely on a unfavorable setup
for this experiment.
28
1.6
200
180
1.5
160
140
Level of Service
1.4
1.3
1.2
120
100
80
60
40
1.1
20
1
4
5
Cut parameter c
10
7.9
7.8
7.7
7.6
7.5
7.4
7.3
4
5
Cut parameter c
4
3
1
3
7.1
1
4
5
Cut parameter c
7.2
4
5
Cut parameter c
Figure 6.7: Varying Cut Parameter Results
29
150
100
50
4
5
Cut parameter c
Figure 6.8: Varying Cut Parameter Computation Time
6.4
Varying Maximum Level of Service
The idea of this experiment is to compare the developed intelligent transportation system to a usual taxi service. Setting the maximum allowed level
of service to 1, makes our system work exactly like a taxi service. The actual
time spend in the vehicle equals the direct ride time. Vehicles pick passengers
up, bring them to their desired dropoff location and continue with the next
closest request. Shared rides are not possible. By increasing the maximum
level of service we can continuously transfer this taxi system into our intelligent transportation system and observe how quality measures change. The
setup of this experiment is shown in figure 6.9.
Figure 6.10 shows the results for this experiment. Not surprisingly the
average level of service values increase as the maximum allowed level of service grows. At this point it is rather essential that by relaxing the maximum
allowed level of service, the total travel time and the number of used vehicles
decrease. This was the original idea of this thesis and now is well documented
with the given results. For example setting the maximum allowed level of
service ml = 4 leads to an average level of service under 1.6 and an average delay of service of about 2 minutes. Therefore total travel time can be
reduced 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
30

Request Generation
Request Conversion
ml
Online Update
Request Allocation
Request Insertion
no
Feasible
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
Figure 6.9: Varying Maximum Level of Service Experimental Setup

system shifting from a usual taxi service without shared rides to a highly
complex intelligent transportation system.
31
250
2.8
2.6
200
Level of Service
2.4
2.2
2
1.8
150
100
1.6
1.4
50
1.2
1
3
4
Maximum Allowed Level of Service
3
4
10
11
10
9.5
9
9
8.5
8
7.5
7
8
7
6
5
4
3
2
6.5
6
1
1
3
4
3
4
Figure 6.10: Varying Maximum Level of Service Results
150
100
50
3
4
Figure 6.11: Varying Maximum Level of Service Computation Time
6.5
Pickup vs Dropoff Proximity
Figure 6.12 shows the setup of an experiment to analyze the systems reaction to varying weights for pickup/dropoff proximity. This is particularly
interesting, because it influences the request allocation, which is decoupled
32
from the rest of the system. Improvements made here could be integrated
inexpensively in terms of computation time.
Request Generation
Request Conversion
Online Update
pp
pd
Request Allocation
Request Insertion
no
Feasible
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
Figure 6.12: Pickup vs Dropoff Proximity Experimental Setup

The results in figure 6.14 indicate that there are some interesting balancing possibilities. Level of service and total travel time occur to be inversely
proportional to each other. Giving more weight to the pickup proximity
leads to lower level of service (which is desirable), but higher total travel
time (which is undesirable). More weight for the dropoff proximity leads to
higher level of service, but lower total travel time.
Computation times in 6.14 do not show significant changes.
33
1.5
140
1.45
1.4
120
Level of Service
1.35
1.3
1.25
1.2
100
80
60
1.15
40
1.1
20
1.05
1
0.1
0.2
0.3
0.4
0.5
0.6
pp = 1pd
0.7
0.8
0.9
0.1
10
8.8
8.6
8.4
8.2
8
7.8
7.6
7.4
0.4
0.5
0.6
pp = 1pd
0.7
0.8
0.9
0.9
7
6
5
4
3
2
7.2
7
0.3
0.2
1
0
0.1
0.2
0.3
0.4
0.5
0.6
pp = 1pd
0.7
0.8
0.9
0.1
0.2
0.3
0.4
0.5
0.6
pp = 1pd
0.7
0.8
Figure 6.13: Pickup vs Dropoff Proximity Results

40
35
30
25
20
15
10
5
0
0.1
0.2
0.3
0.4
0.5
0.6
pp = 1pd
0.7
0.8
0.9
Figure 6.14: Pickup vs Dropoff Proximity Computation Time
6.6
Average vs Maximum Value Optimization
The objective function for one route includes the average quality measure
values and the maximum quality measure values. By choosing the weights
ka and km we can decide if we want to minimize the average values or the
34
maximum values. Simply put we can choose if we want to optimize more

for the average passenger or the worst case passenger. Figure 6.15 shows the
experiments setup.
Request Generation
Request Conversion
Online Update
Request Allocation
Request Insertion
no
Feasible
ka, km
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
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 and
a small increase of delay of service.
35
1.5
140
1.45
1.4
120
Level of Service
1.35
1.3
1.25
1.2
100
80
60
1.15
40
1.1
20
1.05
1
0.1
0.2
0.3
0.4
0.5
0.6
ka = 1km
0.7
0.8
0.9
0.1
10
8.8
8.6
8.4
8.2
8
7.8
7.6
7.4
0.4
0.5
0.6
ka = 1km
0.7
0.8
0.9
0.9
7
6
5
4
3
2
7.2
7
0.3
0.2
1
0
0.1
0.2
0.3
0.4
0.5
0.6
ka = 1km
0.7
0.8
0.9
0.1
0.2
0.3
0.4
0.5
0.6
ka = 1km
0.7
0.8
Figure 6.16: Average vs Maximum Value Optimization Results

40
35
30
25
20
15
10
5
0
0.1
0.2
0.3
0.4
0.5
0.6
ka = 1km
0.7
0.8
0.9
Figure 6.17: Average vs Maximum Value Optimization Computation Time
6.7
Level of Service vs Total Travel Time Optimization
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.
36

wd and ww are both 0. We expect inversely proportional results.
Request Generation
Request Conversion
Online Update
Request Allocation
Request Insertion
no
Feasible
wl, w d, w w, w t
yes
Cost Calculation
no and
no vehicles left
Drop Request
Cut
Figure 6.18: Level of Service vs Total Travel Time Optimization Experimental Setup
Results in 6.19 consequently show that optimizing for level of serve leads
to lower level of service and higher total travel time values and optimizing
for total travel time leads to higher level of service and lower total travel
time values. Delay of service values behave inversely proportional to level of
service values too. Interestingly the number of used vehicles does not change
in this experiment.
37
1.5
140
1.45
1.4
120
Level of Service
1.35
1.3
1.25
1.2
100
80
60
1.15
40
1.1
20
1.05
1
0.1
0.2
0.3
0.4
0.5
0.6
wl = 1wt
0.7
0.8
0.9
0.1
10
8.8
8.6
8.4
8.2
8
7.8
7.6
7.4
0.4
0.5
0.6
wl = 1wt
0.7
0.8
0.9
0.9
7
6
5
4
3
2
7.2
7
0.3
0.2
1
0
0.1
0.2
0.3
0.4
0.5
0.6
wl = 1wt
0.7
0.8
0.9
0.1
0.2
0.3
0.4
0.5
0.6
wl = 1wt
0.7
0.8
Figure 6.19: Level of Service vs Total Travel Time Optimization Results
30
25
20
15
10
0.1
0.2
0.3
0.4
0.5
0.6
wl = 1wt
0.7
0.8
0.9
Figure 6.20: Level of Service vs Total Travel Time Optimization Computation Time
Chapter 7
Conclusion
The results conducted in this thesis show that from a theoretical point of view
it is possible and meaningful to use the presented intelligent transportation
system. Computation times are reasonable even for large data sets as they
occur in urban areas and the experiments made indicate high potential to
further 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 presented
system only needs a little more than half of the vehicles a taxi service would
need to serve the same requests. This advantage for the provider can be
transfered to a price reduction for the passenger, who in return has to be
willing to spend in average 1.6 times the time in the vehicle compared to a
taxi.
To really implement the proposed system it is necessary to incorporate
uncertainties. The system has to be prepared for passengers that do not show
up, traffic jams or vehicle breakdowns to function in a real life environment.
38
Bibliography
[1] Alberto Colorni and Giovanni Righini. Modeling and optimizing dynamic
dial-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 insertion technique of unexpected customers for a dynamic dial-a-ride problem. European Journal of Operational Research, 175(3):1605 1615, 2006.
[4] Dusan Teodorovic and Gordana Radivojevic. A fuzzy logic approach to
dynamic dial-a-ride problem. Fuzzy Sets and Systems, 116(1):23 33,
2000.
39

Intelligent Transportation System: Master Thesis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intelligent Transportation System: Master Thesis

Uploaded by

Copyright:

Available Formats

Autonomous Systems Lab

Prof. Roland Siegwart

Intelligent Transportation System

2 Problem Formulation and Definitions

4 Approach: Preliminary Work

6 Experiments and Results

Varying Cut Parameter . . . . . . . . . . . . . . . .

Figure 1.1: Outline: Intelligent Transportation System

Figure 2.1: Vehicles V and Requests i

CHAPTER 2. PROBLEM FORMULATION AND DEFINITIONS

Serve as many demands as possible

CHAPTER 2. PROBLEM FORMULATION AND DEFINITIONS

Precedence: At no time a drop-off i can occur before its dedicated

CHAPTER 3. LITERATURE REVIEW

dynamic DARP presented here are heuristics.

CHAPTER 3. LITERATURE REVIEW

CHAPTER 4. APPROACH: PRELIMINARY WORK

Figure 4.1: Map: Zurich

Figure 4.2: Vehicle Model

CHAPTER 4. APPROACH: PRELIMINARY WORK

Figure 4.3: Simulation Environment

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM

Figure 5.1: System Overview

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM

Figure 5.2: Time Windows

(a) Arrival Times

(b) Destination Times

(d) Latest Arrival Times

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM

Figure 5.4: Decision Step

To allocate a request to a specific vehicle first the vehicles are prioritized as

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM

When a request is to be inserted into a schedule, both the insertions of pickup

Figure 5.5: Request Insertion

Time Window Insertion

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM

Figure 5.6: Window Insertion

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM

Insert in between: Feasibility is checked. If insertion is feasible, the

CHAPTER 5. APPROACH: SCHEDULING ALGORITHM

Figure 5.7: Cost Calculation

CHAPTER 6. EXPERIMENTS AND RESULTS

Figure 6.1: Experimental Setup

CHAPTER 6. EXPERIMENTS AND RESULTS

Figure 6.2: Standard values used in all experiments

CHAPTER 6. EXPERIMENTS AND RESULTS

Figure 6.3: Online vs Offline Experimental Setup

CHAPTER 6. EXPERIMENTS AND RESULTS

(a) Level of Service

(b) Delay of Service

Number of used Vehicles

Total Travel Time [h]

(c) Total Travel Time

(d) Number of used Vehicles

Figure 6.4: Online vs Offline Results

Computation Time [s]

Figure 6.5: Online vs Offline Computation Time

CHAPTER 6. EXPERIMENTS AND RESULTS

Varying Cut Parameter

Figure 6.6: Varying Cut Parameter Results Experimental Setup

CHAPTER 6. EXPERIMENTS AND RESULTS

(c) Total Travel Time

(b) Delay of Service