Validation for a Dial-A-Ride software and a sensitivity analysis · 2018-11-29 · 2.2 Vehicle...
119
Validation for a Dial-A-Ride software and a sensitivity analysis Facoltà di Ingegneria Civile ed Industriale Dipartimento di Ingegneria Civile Corso di laurea in Transport Systems Engineering Candidato: Matteo Giaconi Matricola 1482891 Relatore Correlatori Guido Gentile Alessandro Attanasi Marco Pezzulla A/A 2017/2018
Transcript of Validation for a Dial-A-Ride software and a sensitivity analysis · 2018-11-29 · 2.2 Vehicle...
Validation for a Dial-A-Ride software and
a sensitivity analysis
Facoltà di Ingegneria Civile ed Industriale
Dipartimento di Ingegneria Civile
Corso di laurea in Transport Systems Engineering
Candidato: Matteo Giaconi
Matricola 1482891
Relatore Correlatori
Guido Gentile Alessandro Attanasi
Marco Pezzulla
A/A 2017/2018
2
Summary
1 Introduction ............................................................................................................................................. 4
1.1 Research field, motivations and aims .......................................................................................... 4
2 Vehicle Routing and Dial-a-ride problems .......................................................................................... 7
2.1 History .............................................................................................................................................. 7
2.2 Vehicle Routing ............................................................................................................................... 8
2.2.1 General characteristics ............................................................................................................ 8
2.2.2 A famous Example: The travelling salesman problem ...................................................... 9
2.2.3 Vehicle Routing categories .................................................................................................. 11
2.3 Dial-A-Ride .................................................................................................................................... 20
2.3.1 Demand Responsive Transports ......................................................................................... 20
2.3.2 Dial-a-ride Problems ............................................................................................................. 21
3 An Algorithm for DARP ...................................................................................................................... 26
3.1 Introduction ................................................................................................................................... 26
3.2 Jaw Algorithm (1984-86) .............................................................................................................. 28
3.2.1 Logic Notes ............................................................................................................................ 28
3.2.2 Problem Formalization and Operating Scenario .............................................................. 29
3.2.3 Algorithm Overview ............................................................................................................ 33
3.2.4 Processing of a generic customer ........................................................................................ 34
3.3 DARP (2004) ................................................................................................................................... 46
3.3.1 Software Implementation Structure ................................................................................... 46
3.3.2 New Implementations .......................................................................................................... 47
3.4 DARS .............................................................................................................................................. 51
3.4.1 Main Characteristics, Input loading and simulation outcomes ..................................... 52
3.4.2 Street Graph and Dynamicity .............................................................................................. 55
3.4.3 Insertions ................................................................................................................................ 57
3
3.4.4 Requests .................................................................................................................................. 63
3.4.5 Vehicle Fleet ........................................................................................................................... 64
3.4.6 Vehicle Search Function ....................................................................................................... 65
3.4.7 Cost functions ........................................................................................................................ 68
4 Test Phase ............................................................................................................................................... 72
4.1 Testing Environment .................................................................................................................... 72
4.2 Specific and operational simulations ......................................................................................... 73
4.3 Specific Tests .................................................................................................................................. 75
4.3.1 Test 1 ....................................................................................................................................... 76
4.3.2 Test 2 ....................................................................................................................................... 83
4.3.3 Test 3 ....................................................................................................................................... 87
4.4 Aggregated test and operational conditions ............................................................................. 92
4.4.1 First Scenario .......................................................................................................................... 94
4.4.2 Second Scenario ..................................................................................................................... 96
4.4.3 Third Scenario ........................................................................................................................ 99
4.4.4 Fourth scenario .................................................................................................................... 102
4.4.5 Fifth Scenario ....................................................................................................................... 105
5 Conclusions and discussion............................................................................................................... 109
6 Appendix .............................................................................................................................................. 110
7 Acknowledgments .............................................................................................................................. 115
8 Literature Index ................................................................................................................................... 117
4
1 Introduction
1.1 Research field, motivations and aims
This work was conceived as a deep analysis of a Dial-A-Ride optimization software colloquially
known as DARS, with a focus on its sensitivity, meaning a step by step analysis of the software
response given a certain dataset which changes only on particular and pre-set conditions.
This process has been realized in order to better understand the software limitations, its strengths
and the magnitude of problems it may handle.
While it doesn’t aspire to be a full and overall coverage of software possibilities and limits, this
dissertation serves as a closer look for research purpose about the software state-of-art and gives a
quick overview of the industry innovation about the real-time transportation field.
We are living in an era in which it is expected from a transport system to be efficient, fast,
sustainable and with the lowest possible cost for a user.
Numerous examples are nowadays present anywhere around us.
Every App Store contains an high number of products designed exclusively to upgrade any travel
inside or outside the urban space at its best and, sometimes, these apps are just a few “slides”
away to getting downloaded and used for free.
The modern trends are suggesting an increasing interest about real-time and transport related
solutions which sometimes lead to the possibility of not even owning a car for personal purposes.
In its small scale, this thesis also aims to exploit the difficulties and issues arising when trying to
build a tool capable of offering this type of services.
In fact, while the researches on these topics have been wide and numerous, it is not always
obvious that a theoretical work could be later shaped on a real-world scenario.
The Dial-A-Ride services often rely on very complex theory and surely need the right technological
tool to deliver their services.
The Dial-A-Ride problems (DARP’s) are named after the service and are part of a larger group of
problems known as Vehicle Routing problems.
While this dissertation widely mentions Vehicle Routing problems, for the sake of clarity and
focusing, these are not treated as deeply as Dial-A-Ride problems.
5
Anyway, a good range of examples and formulation are mentioned to have a better view of the
parts treating DARP’s.
This dissertation focus on a particular formulation from which the software has been firstly
originated and then rebuilt.
This particular formulation, whom origins are treated in a high level of detail, would be enough to
correctly frame and confront the problem without the needing of adding more.
On the other hand, it seemed a good step to add a more general introduction and theoretical
structure regarding other types of Dial-A-Ride problems that have been investigated throughout
the years.
Of course, this decision has been taken thinking about the fact that comparing different
formulations, theory and intuitions could lead to a better shaped result, maybe taken into
consideration a wider group of hypotheses and assumptions.
While this might seem a surplus it is indeed the best way to have a clear view of the different
developments and betterments it had during the years, highlighting such a great attention to
details.
The theory and software evolutions underline the different needing that characterized different
periods.
In fact, while the kind of scenarios tackled in the early 80’s are now outdated, the core
characteristics of the treatment proved to be still applicable to the modern times issues and
requests, when appropriately modified and elaborated.
A good part of the thesis has been dedicated to sort out the last version of the software functions
and main characteristics.
This step has been done to make any reader understand the type of tool that has been used for the
operations.
It is also worth mentioning the fact that, before even start testing the software, an high amount of
work has been done on understanding its principal structures and insight connections, for instance
studying directly the software source code.
This “reverse engineering” phase of extrapolating the functional theory directly from the software
has been crucial, since it could be considered a proper “debug” phase the program has underwent
into.
6
Some parts of the software have been modified “on-the-go to calibrate the different reactions the
software may have showed during the analysis.
After this first passage, the natural following has been to make the software pass through a more
detailed kind of tests (Specific tests), before examining the results on an operational scale, which is
more massive and, because of its definition, harder to interpretation.
The tailored tests prepared a-priori are in fact a second “debug” layer, because tackled the
different single functionalities.
The explanation of these tests were made to make the reader understand the type of mental path
used to search and verify that the software main components were all fine.
Eventually, after all these preparation passages, a real-time aggregated analysis has been
performed under different Scenarios.
More specifically, the aim was to measure the type of software performance when pushed to
increasingly “harder” constraints while keeping the lowest possible amount of operational and
overall costs.
The analysis must have to be taken as a good representation of the software capacity to handle
extreme situations on an actual real-time scenario.
The data extracted from the numerous runs have been selected and presented to underline the
differences between one and the other.
Eventually, the dissertation not only shows the software working in its internal mechanism but
explores and calibrates the extreme conditions the software is capable of tackle so far at this stage
of development.
7
2 Vehicle Routing and Dial-a-ride problems
2.1 History
Researches have been numerous and wide in terms of tackling the different levels of Vehicle
Routing and Dial-A-Ride problems.
The taxonomy of these problems (Psaraftis et al.) dates back a high number of researches about the
dynamic vehicle routing problems to the late 70s of the last century. After the year 2000 this field
had witnessed a real explosion (.sic)
Several researchers focused their studies on different aspects of the problem which, as it easy to
understand, has a very complex theoretical construction. Even in its smaller versions, to find the
“optimal” solution it is usually very hard.
These kinds of problem are often NP hard, which means resolution goes through heuristic
algorithms in which, by definition, the global optimum is not a-priori guaranteed.
So, apart from a real good understating of the math instruments, it likely requires coding and a
good amount of calculation power.
Dial-A-Ride problems are a natural consequence of the VRP problems. Dial a ride services existed
in the late 70s already onto different aims: to give a help to people who didn’t own a personal
vehicle and had problems about using the public transport, as a schedule service for school buses
(Bodin).
The first reference to a computer controlled Dial-a-Ride model dates back in 1977 (Wilson and
Colvin, MIT Technical report), more than 40 years ago. Although the interest about DAR grew up
very soon we had the biggest steps ahead during the last 20 years (as mentioned right above). It
took a little to shift from what was a little more than a mathematical challenge to a real project and
design of an operational problem, in which a good amount of user can call a preferred door to
door service which very often needs to be updated in a few seconds span. This basically means
that technology didn’t seem developed enough to stick this kind of construction to a real-world
situation.
Even though the mobile technology had started to be getting more and more weight on the
average, still a lot was missing.
It would have been strange (if not impossible) to find a GPS on a casual city car or a taxi and
8
absolutely unimaginable on a mobile device designed to making calls (AKA not-that-smart
cellphone).
Their incredible development during the new millennium forced the evolution of the DAR service,
which needed to transform itself from a “24 hour prior call” to an immediate, reliable public
transport alternative.
The results are clear and this type of service now aim to a be more and more intergrated inside any
city texture, wnlarging their aim to the entire population.
The most famous examples of this wide integration are given of course by apps, such as Uber and
Lyft. Even if these companies are not just to praise, they surely contribute to make excitement
grow around the VRP and DAR issues, since it is proven once and for all that these question are an
absolute priority.
The following paragraphs have the role of presenting the general mathematical construction of
these problem, their complexity classification and the papers that have been fundamental to
achieve the kind of consideration we have today.
2.2 Vehicle Routing
2.2.1 General characteristics
The Vehicle Routing problem (VRP) “calls for the determination of the optimal set of routes to be
performed by a fleet of vehicles to serve a given set of customers” (Toth et al.).
It is one of the most important and yet studied combinatorial optimization problem.
The problem has been introduced by Dantzig and Ramser in 1959, by describing a real-world
application concerning the delivery of gasoline to service stations. The two proposed the first
mathematical programming formulation and algorithmic approach.
Anther seminal paper has been delivered by Clarke and Wright, and it is particularly important
because they proposed an effective greedy heuristic.
By definition, a greedy heuristic is an algorithmic paradigm that follows the problem solving
heuristic of making the locally optimal choice at each stage, hoping to find a general optimum (or
global optimum).
9
Following these first two publications, dozen followed whit hundreds of algorithms and
mathematical structure.
It is easy to imagine why, since this kind of problems are surely complex but also absolutely
interesting for the kind of application that are possible in a real-world environment.
To determine the optimal solution to VRP is NP-hard (non-deterministic polynomial time
hardness), so the size of the problems solvable by using programming or combinatorial
optimization is (or may be) limited.
2.2.2 A famous Example: The travelling salesman problem
One of the most representative and most cited examples of VRP it’s surely the Travelling Salesman
Problem (TSP). The problem asks the following question: “given a list of cities and the distances
between each pair of cities, what is the shortest possible route that visits each city and returns to the origin
city?”.
Even if the origin dates back to the 19th century, the problem firstly appeared on a 1930 salesman
book (without any mathematical formulation), and it has been since then one of the most
intensively studied problems in optimization, so much that is used as a benchmark for many
optimization methods (Wiki).
The easiest version might be an undirected, symmetric and weighted graph in which the cities
coincides with the geometrical vertexes and every arc has its cost in terms of travelling.
10
Figure 2-1 - A loop connecting all the destinations just once (Source: Wikipedia)
The TSP has the merit of having stimulated the studies around the issue of finding an optimal
solution with a reasonable amount of computations.
There are several methods to solve this type of problems.
The “easiest” in terms of comprehension would be to force all the possible permutation and see
which one of these results to be the cheapest.
Even thou this solution it’s always possible theoretically, it’s polynomial running time is set on
𝑂(𝑛!), where n is the number of the cities in the scheme.
So, having more than 15 cities makes this kind of approach absolutely inadvisable.
As a natural consequence, a large number of algorithms have been developed based on this
problem, which has a lot of different variations.
Instead of a long list of those, it is more useful to do a distinction between exact algorithms and
heuristic algorithms. The fist category is, as the name itself may suggests, a class per se which aims
to solve the problem without leaving any room for mistakes, while the latter category tries to
achieve the best possible compromise between speed, precision and accuracy.
11
In terms of computational weight, it still has to be demonstrated that an exact algorithm for TSP is
capable of running to a higher speed of 𝑂(1.999𝑛) (Woeginger).
2.2.3 Vehicle Routing categories
As mentioned before, throughout the years this problem has been treated by many researchers
with many starting hypotheses around it which enlarged the TSP initial concept.
It is important to keep in mind that many of these categories are important in order to mirror some
real-world problems. In fact, the operational problems that some services like logistics or private
transport may face have to be modelled following a strong mathematical formulation that permits
to obtain good reliable results without resulting too tough to compute in a reasonable time.
The following subparagraphs aim to present the most relevant models and some examples to
better understand their field of application, as presented in numerous papers (R. Larsen, A Larsen,
etc.)
2.2.3.1 Static VRP
The Static Vehicle Routing problems are the simpler sub-category of the whole branch.
As the name suggests, the whole problem is treated as static, in the sense of having given
conditions at the beginning of our analysis, conditions that are not supposed to change during the
whole operational time.
These are for example the travel times between nodes, demand, number of customers and
vehicles.
It is fine to confirm that time is not taken explicitly into consideration in these specific extensions
of the problem.
12
Figure 2-2: Standard VRP
So, briefly, all the data necessaries to solve a problem are known a-priori and do not requires a
continuous update of data.
A good application of this problem may be goods delivery between depots whose position is fixed
and in certain time of the day (ex. Late night) in which considering fixed travel times cost is
possible. In this particular case, the calculation could be done a good amount of hour before
actually starting the operations, since the variance from the average values we use to obtain the
optimal solution is basically null.
The logic construction described so far is also known as deterministic. The reason for that is its
absolutely absence of any randomness.
To add the stochastic element information’s must change according to some known (or unknown)
distribution. A good example to understand this difference might be the waste collection for
private households: it is possible to model everything in advance of the operation time, but with a
randomness in its elements, so for example the oscillation from the average value of the amount of
waste to be collected. This oscillation could be done with the usage of historical series or any other
statistical instrument which allows to forecast the chosen period.
In case of having a bigger amount than the previous day, the problem would change its structure,
involving for example more vehicles and/or different route to optimize the scenario.
13
2.2.3.2 Dynamic Vehicle Routing and Time Windows
Some very important logical additions to the standard VRP problem are the Dynamic (DVRP)
aspect and the Time Windows constraints (DVRPTW).
The dynamic problem is defined as: “in DVRP the input on the problem is received and updated
concurrently with the determination of the route” (Psaraftis et al.).
The Dynamic characteristic is fundamental for almost every modern study or, at least, anything
that has been studied after 2000. The reason why, as mentioned before, is the stunning explosion of
the mobile technologies which created the brand-new market segment of the actual real time
transportation.
It may seem reductive to address technology as the major reason why the researches about DVRP
have been carried on with such a great enthusiasm, but this thesis is shared by many scholars
(Psaraftis, Larsen, etc.).
The main aspects for this progression have been in particular:
➢ Advances in computing power and its household diffusion.
It is anyway important to notice that the empowered calculation doesn’t immediately
correspond to a possibility of enlarging by the same order of magnitude the problem
dimension. To explain in better terms, Psaraftis takes as an example the memory expansion of a
calculator. Assuming a TSP could have been solved in the 70s with a maximum of 20 nodes,
with a 106 increase of storage capacity and the same algorithm now could be solved enlarged
to 28 nodes.
Anyway, this is not true for heuristic approaches, whose memory requirements grows
polynomially with problem size.
➢ Global Positioning Systems (GPS), Geographical Information Systems (GIS) and Intelligent
Transportation Systems (ITS).
These field are deeply interconnected with each other and their development reflected on
transportation field. A continuous control over any type of vehicle fleet exploited numerous
and useful applications: commercial ones such as logistics and delivery services, as well as
private such as traffic control and forecasting.
14
➢ Big Data and Predictive Analysis.
Big Data refers to the manipulation of very large datasets that, in the past, could not be
handled. The field have drawn an enormous amount of attention from a lot of different field of
application, especially operational researchers.
Predictive analysis is instead a related concept that uses a variety of statistical techniques from
modelling to machine learning; the aim is of course to analyse real-time and historical facts in
order to make predictions about future or any kind of unknown event.
➢ The outstanding growth of portable devices and the diffusion of position signalling devices to
a household level.
Reprising the first two points of the computer advances, it is also very important to underline
the game-changing role of portable devices which unite a great amount of computing power
and quick connectivity with the possibility to track the position of the device itself in a matter
of seconds.
Apart from technology, it is not to be neglected in the equation the budget which has been used by
EU to fund ICT and transports, which settles at around 2.5 billions euros combined (data reported
by DTU university).
The deeply useful work by Psaraftis et al. aims to build a taxonomy for the DVRP, in order to
catalogue the work that has been done and to determine the significant path to follow in the
immediate future.
While the base is Dynamic Vehicle Routing, the author divides researches by eleven different
criteria, giving a more distinct frame.
15
16
Taking a closer look to the prior page, it is immediately noticeable that, as for the static VRP, also
in DVRP there is a first division between Deterministic and Stochastic problems.
To understand better what kind of information’s are part of one or the other group it could be
useful to tackle a real life situation.
Let’s consider any city-based service which involves any sort of pickup and/or delivery of
customers; the number of those is likely to change during different times of the same day in a
reasonable way.
A Deterministic Dynamic problem is not a problem in which any future input is known in
advance, instead this implies having no stochastic information (probability or probability
distribution) about any future, dynamically evolving input.
For instance, nothing may be known about the location of a customer until that same customer
request service; or nothing may be known about the quantity to be demanded until when that
information is revealed.
A Dynamic problem is labelled as Stochastic if, on the contrary, some probabilistic information is
known about the inputs that dynamically evolve, and for instance routes are updated as these
inputs evolve in time.
To bring another example, it is possible to assume that demand at a customer location could follow
a certain probability distribution; the actual value of the demand is later revealed when the vehicle
physically visit the location.
Some publication too k into consideration this typology, modelling services such as real-time
delivery of urgent goods (2013, Ferrucci et al.) or a more generical analysis of minimum expected
total cost from O to D that anticipates and responds to service requests (2004, Thomas and White).
VRP CLASSIFICATION STATIC DYNAMIC
DETERMINISTIC
All data known in advance and
time is not taken into account
explicitly.
Planning is done when the day
operation begins.
All data is deterministic, but
not known in advance.
STOCHASTIC
Routes are designed at the
beginning of the planning
horizon before uncertain data
become known
Uncertain data (for instance
user requests) are represented
by stochastic processes.
Data are gradually revealed.
Table 1 - VRP classification
17
An interesting measure for a DVRP has been formulated by Lund et al. by the name of Degree of
Dynamism ( 𝛿 ). In this case measure can be seen some way as the number of dynamic operation to
achieve in determined Planning horizon [0 , T].
Figure 2-3 - Degree of dynamism representation
The occurrence time (request time) 𝑡𝑖 ∈ [0 , 𝑇] and the number of static 𝑛𝑠 and dynamic 𝑛𝑑 request
complete the data set to determine 𝛿.
In the example above we have 7 static requests at the 0 instant (since are known a-priori) and 3
dynamic requests within the planning horizon.
The formula for the degree of dynamism has been defined as:
𝛿 = 𝑛𝑑
𝑛𝑑 + 𝑛𝑠
It is pretty easy to calculate the result which is 3.
A fundamental addition to the logical construction of the problem is the consideration of Time
Windows, so that a problem can be called Dynamic Vehicle Routing Problem with Time Windows
(DVRPTW).
A Time Window is an additional constraint to the problem and it perfectly represent the problem
of assuring “deliveries on time”.
To explain the concept a little better (even though it is easy imaginable), Time Windows are added
to any operation, so there will be a an open time for the operation to be satisfied. In case of a
people transport service you’ll have a pick up time which is non shiftable to an earlier instant.
With the same mindset it is easy to understand that there will be a closing time of the window, so
that a delivery may not be completed after a certain date/time. A good example of this boundary
might be the closing time of a shop which needs to receive the goods of the day.
18
This restriction is pretty important when it comes to operational quality of service, since it
represent the boundaries inside which the service must take place in order to satisfy the minimum
requirements of whomever is using it.
Because of it ‘s central part and its implications, Time Windows make this kind of problems way
more complex from a mathematical point of view.
2.2.3.3 A mathematical model for VRPTW
A rigorous formalization of the VRPTW has been given by many researchers with different
degrees of complexity because of their different aims. A work that is particularly interesting has
been delivered by El-Sherbeny (2009, Al-Azhar University). Even though this paper went into
deeper levels of the problem which aren’t really related to the aim of this course, the standard
formulation is clear and explains the most important sides of the problem.
VRPTW is given by: V as a fleet of homogeneous vehicles, C as a set of customer and G = (V, C) as a
directed graph. The graph consists of |C| + 2 vertices, having 0 (in this case the driving out depot)
and n + 1 (the returning depot) as the vertexes.
The aim of VRPTW is to minimize the not only the number of vehicles required, but also the total
travel time, waiting time and total travel distance incurred by the fleet of vehicles.
The set of Arcs A represents the connections between the depot and customers and the customers
themselves. No arc terminates in vertex 0 and no arc originates from vertex n + 1.
Each arc (i , j) has i≠j and is associated with a cost 𝑐𝑖𝑗 and a time 𝑡𝑖𝑗 (which includes a service time
at customer i).
Each vehicle has a capacity q and each customer i a demand 𝑑𝑖.
Each customer has a time window [𝑎𝑖 𝑏𝑖]. As a general rule: a vehicle must arrive before b and if it
arrives before a it will need to wait. The depot also has a time window [𝑎0 𝑏0], so vehicles may not
leave the depot before 𝑎0 and must be back before or at time 𝑏𝑛+1.
It is assumed that 𝑞, 𝑎𝑖, 𝑏𝑖, 𝑑𝑖 , 𝑐𝑖𝑗 are non-negative integers, while the 𝑡𝑖𝑗 are assumed to be positive
integers.
19
It is assumed that the triangular inequality is satisfied for both the 𝑐𝑖𝑗 and 𝑡𝑖𝑗. The model contains
two sets of decision variables 𝑥𝑖𝑗𝑘 and 𝑠𝑖𝑗𝑘.
For each arc (i , j), where 𝑖 ≠ 𝑗 , 𝑖 ≠ 𝑛 + 1, 𝑗 ≠ 0, and for each vehicle k we define 𝑥𝑖𝑗𝑘 = 1 if and
only if is the optimal solution; arc (i , j) is traversed by vehicle k and equal 0 otherwise.
The decision variable 𝑠𝑖𝑗𝑘 is defined for each vertex i and each vehicle k and denotes the time
vehicle k starts to service customer i. In case a vehicle k does not service customer i, 𝑠𝑖𝑗𝑘 doesn’t
mean anything.
We assume 𝑎0 = 0 and therefore 𝑠0𝑘 = 0 for any k.
The aim is to design a set of minimal cost routes (one for each vehicle) such that each customer is
visited exactly once; plus, every route should originate at vertex 0 and end at vertex n+1, and the
time windows with the capacity constraints should be observed.
We can state the mathematical DVRPTW as follows:
𝑚𝑖𝑛 ∑ ∑ ∑ 𝑐𝑖𝑗𝑥𝑖𝑗𝑘
𝑗∈𝑁𝑖∈𝑁𝑘∈𝑉
(2.2.1)
And the consequent constraints
∑ ∑ 𝑥𝑖𝑗𝑘𝑗∈𝑁𝑘∈𝑉 = 1 ∀𝑖 ∈ 𝐶 (2.2.2) ∑ 𝑑𝑖 ∑ 𝑥𝑖𝑗𝑘𝑗∈𝑁𝑖∈𝐶 ≤ 𝑞 ∀𝑘 ∈ 𝑉 (2.2.3)
∑ 𝑥0𝑗𝑘𝑗∈𝑁 = 1 ∀𝑘 ∈ 𝑉 (2.2.4) ∑ 𝑥𝑖ℎ𝑘𝑖∈𝑁 - ∑ 𝑥ℎ𝑗𝑘𝑗∈𝑁 = 0 ∀ℎ ∈ 𝐶 ∀𝑘 ∈ 𝑉 (2.2.5)
∑ 𝑥𝑖,𝑛+1,𝑘𝑖∈𝑁 = 1 ∀𝑘 ∈ 𝑉 (2.2.6) 𝑠𝑖𝑘 + 𝑡𝑖𝑗 − 𝐾(1 − 𝑥𝑖𝑗𝑘) ≤ 𝑠𝑖𝑗𝑘 (2.2.7)
𝑎𝑖 ≤ 𝑠𝑗𝑘 ≤ 𝑏𝑖 (2.2.8) 𝑥𝑖𝑗𝑘 ∈ {0 , 1}, ∀𝑖, 𝑗 ∈ 𝑁 , ∀𝑘 ∈ 𝑉 (2.2.9)
The constraints (2.2.2) states that each customer is visited just once, while (2.2.3) means that no
vehicle is loaded with more capacity than it is allowed to.
The (2.2.4) ensure that each vehicle leaves the depot 0, (2.2.5) states that after arriving to a
customer the vehicles leaves again, while (2.2.6) eventually put a constraints on vehicle final
arrival, which is of course the depot n+1.
The inequality (2.2.7) state that a vehicle k travelling from i to j cannot arrive before 𝑠𝑖𝑘 + 𝑡𝑖𝑗, when
in this case K is a large scalar.
Eventually, constraints (2.2.8) ensure that time windows are respected and (2.2.9) are integrity
constraints.
20
In this model, an unused vehicle is modelled as it drives the empty route between (0, n + 1).
Of course, it is possible to generalize the problem to more specific cases, such as non-identical
vehicles, multiple depots or the extremely applicable case of multiple Time Windows.
2.3 Dial-A-Ride
2.3.1 Demand Responsive Transports
For Demand-Responsive transport is an advanced, user-oriented form of public transport
characterised by flexible routing and scheduling of small/medium vehicles operating in shared-
ride mode between pick-up and drop-off locations according to passenger’s needs (European
commission directorate for energy and transport).
The applications of DRT are, for instance, public transport service for areas of low passenger
demand (such as rural areas) where regular bus service would not be available, transport patients
(or elderly people) to home after visiting hospital (or any important need), paratransit services (in
the form of minibuses, shared taxis, etc…) and general Dial-A-Ride buses.
A famous and efficient example is the London Dial-A-Ride which is focused on transport for
disabled people.
Generally speaking, the DRT services work with a user who books his journey to a dispatcher
whom function is to redirect the request to a vehicle (or a group of those) which will later satisfy it.
The next paragraph will focus on the formalization of the Dial-A-Ride problems which, as
explained, are taken into the wider category of Demand Responsive Transports.
21
Figure 2-4 - DRT Examples and expected response time
2.3.2 Dial-a-ride Problems
Dial-a-Ride problems (DARP from now on) are in fact a generalization of VRP’s. In particular the
categories such as the Pickup and Delivery vehicle routing problem (PDVRP) and of course the
Vehicle and Routing problems with Time Windows (VRPTW).
The prodigious work by Cordeau and Laporte helps to check the state of the research (even though
the paper is from 2007 so not properly updated to the actual situation) and gives an historical
perspective of this services.
DARP consists of designing vehicle routes and schedules for n users who specify delivery and
request between origins and destinations.
The aim is to set a of m minimum cost vehicles routes capable of accommodating as many users as
possible under a reasonable set of constraints.
22
Common examples of this model are door-to-door services for disabled and elderly people, for
which it’s possible to find examples from the early 70s of the last century. Because of this
characteristic it is often considered an outbound and a return trip for any operational day.
Western countries are activating this service more frequently (or empowering the already existing
ones). The paper suppose that this growth is to attribute to the aging of the population and the
trending towards the development of ambulatory health care systems.
Its high applicability to real operational situations make this type of model studied from a lot of
perspectives. In fact, there is an urgent needing to build adequate systems and to update those that
have been proved to be now outdated.
According to Cordeau et al., the aspect that differentiate DARP from the average VR problem is
the “human perspective”. While transporting passengers, reducing the perceived cost (so the
inconveniences and all the related problems) is essential as much as keeping the operating cost to
the minimum possible.
In addition, while in some VRP’s the problem of the vehicle capacity is redundant or negligible, in
any DARP is an absolute central part of the model. The same reflection can be applied to Time
Windows, which have to be taken into consideration for computing the quality of service from a
righteous angle.
As for any VRP, DARP can be both Static or Dynamic.
In the first case, all transportation requests are known beforehand; this condition actually means a
certain anticipation time for any request. The example might be a service in which is possible to
ask for a Pickup or a Delivery at least a day prior to the date needed for the service.
On the other hand, a Dynamic service reveals the requests throughout the day. In practice it is
really hard to find a purely Dynamic DARP, since some conditions are necessarily known in
advance (Cordeau et al.).
Models are different between them in deciding how to treat the depot and the fleet. A vehicles fleet
might be homogeneous or differ in it vehicles typology distribution (for instance, the model
considered in this work does takes into consideration thing) and the depots might as well be
single, numerous and with different functions.
23
According to Cordeau et al., it makes sense to consider two types of problems:
➢ minimize costs subject to full demand satisfaction and side constraints
➢ maximize satisfied demand subject to vehicle availability and side constraints
Some quality of service criteria include time spent on board for any passenger, delays form the
desired time, customer waiting time and route length. It is immediate to see that some of these
criteria might be considered as purely constraints for the problem.
That is the reason why Time Windows must be considered in the resolution.
It might be very hard to correctly solve a problem in which Time Windows are set by users
themselves both for the pickup and for the delivery, because they may not be aware of the actual
reasonable TW.
In some situation problem (like the one later treated and simulated) it is acceptable to consider the
customer as the one choosing the correct Time Window for the pickup (if they are requesting one)
and then calculate the appropriate time span for the delivery. While the delay from the desired
time is translated to a negative weight for the overall final cost, the non-respect of the Time
Window is a boundary that, for its definition, it is not acceptable in terms of a good resolution.
The same logic flow applies of course to deliveries.
2.3.2.1 Mathematical Formulation
As is often the case in Dial-A-Ride contexts, users specify an outbound request from their home to
a destination and an inbound request for the return trip. The word often it is not casual, because
even though the request is fair, and it actually sticks to the truth (an user which leaves his home
tend to organize his journey back and forth), it is often considered as two separate trips in many
mathematical structures and, of course, in software that implement those. PTV Dars is part of this
group, as will be defined deeper on this work.
Cordeau (2006) formulates the DARP on a directed graph G = (V , A).
The vertex set is partitioned into: {{0, 2n + 1}, P, D} where 0 and 2n + 1 are two copies of the depot,
P = {1, . . . , n} is the set of pickup vertices and D = {n + 1, . . . , 2n} is the set of delivery vertices.
A request is a couple (i, n + i), where i ∈ P and n + i ∈ D.
To each vertex 𝑣𝑖∈ V are associated a load 𝑞𝑖, with 𝑞0 = 𝑞𝑛+1 = 0, 𝑞𝑖 ≥ 0 for i = [1, . . . , n] and 𝑞𝑖 =
24
−𝑞𝑖−𝑛 for i = [n + 1, . . . , 2n] , and a service duration 𝑑𝑖 ≥ 0 with 𝑑0 = 𝑑2𝑛+1 = 0.
The arc set is defined as A = {(i, j ): i = 0, j ∈ P, or i, j ∈ P ∪ D, i ≠ j and i ≠ n + j, or i ∈ D, j = 2n + 1}.
The capacity of vehicle k is 𝑄𝑘 and the maximal duration of route k ∈ K is denoted by 𝑇𝑘 .
The cost of traversing arc ( i, j ) with vehicle k is equal to 𝑐𝑖𝑗𝑘 , and the travel time of arc (i, j ) is
denoted by 𝑡𝑖𝑗.
The maximal ride time is denoted by L and the time window of vertex i is [𝑒𝑖, 𝑙𝑖 ].
The model uses binary three-index variables 𝑥𝑖𝑗𝑘 equal to 1 if and only if arc (i, j ) is traversed by
vehicle k ∈ K. In addition, let 𝑢𝑖𝑘 be the time at which vehicle k starts servicing vertex i, 𝑤𝑖
𝑘 the load
of vehicle k upon leaving vertex i, and 𝑟𝑖𝑘 the ride time of user i (corresponding to request (i, n+ i)
on vehicle k).
The model is then as follows:
Minimize ∑ ∑ ∑ 𝑐𝑖𝑗𝑘 𝑥𝑖𝑗
𝑘𝑗∈𝑉𝑖∈𝑉𝑘∈𝐾 (1)
Subject to
∑ ∑ 𝑥𝑖𝑗𝑘
𝑗∈𝑉𝑘∈𝐾 = 1 (i∈P) (2.3.1) ∑ 𝑒0𝑖𝑘
𝑖∈𝑉 = ∑ 𝑥𝑖,2𝑛+𝑖𝑘
𝑖∈𝑉 = 1 (𝑘 ∈ 𝐾) (2.3.2)
∑ 𝑥𝑖𝑗𝑘
𝑗∈𝑉 −∑ 𝑥𝑛+𝑖,𝑗𝑘
𝑗∈𝑉 = 0 (i ∈ P, k ∈ K) (2.3.3) ∑ 𝑥𝑗𝑖𝑘
𝑗∈𝑉 −∑ 𝑥𝑖𝑗𝑘
𝑗∈𝑉 = 0 (i ∈ P ∪ D, k ∈ K) (2.3.4)
ukj≥ (uki+ di +tij) xkij (i, j ∈ V, k ∈ K) (2.3.5) wkj≥ (wki+ qj ) xkij (i, j ∈ V, k ∈ K) (2.3.6)
rki≥ ukn+i−(uki+ di) (i ∈ P,k ∈ K) (2.3.7) uk2n+1−uk0 ≤ Tk (k ∈ K) (2.3.8)
ei ≤ uki≤ li (i ∈ V, k ∈ K) (2.3.9) ti,n+i ≤ rk i≤ L (i ∈ P,k ∈ K) (2.3.10)
max {0, qi} ≤ wki≤ min {Qk,Qk + qi } (i ∈ V,k ∈ K) (2.3.11) xkij= 0 or 1 (i, j ∈ V,k ∈ K) (2.3.12)
In this formulation, constraints (2.3.2) and (2.3.4) ensure that each request is served once by the
same vehicle, while constraints (2.3.3) and (2.3.5) guarantee that each vehicle starts and ends its
route at the depot. Constraints (2.3.6) to (2.3.8) define starts of service times, vehicle loads and user
ride times, respectively, while constraints (2.3.9) to (2.3.12) ensure that these will be feasible.
While this is not the only formulation available (and the publications are surely numerous), it may
be one of the most precise, because of the deep knowledge of the author about DARS publications
throughout the years.
25
2.3.2.2 Static and Dynamic DARPs
The dynamic DARPs have been without a doubt the most investigated branch of the problem.
Even though as said before it is hard to consider a DARP as purely dynamic, it might be
interesting to mention some publications to have a good overview of the different angles.
In particular, the decision has been taken to focus on multi-vehicle cases only because of the nature
of this thesis work.
As already did in the previous paragraph, it is important to distinguish static and dynamic
problems.
The first example of multi-vehicle static DARP was provided by the pioneer’s work of Jaw et al.
(1986), even though a big part of his studies on the topic were presented a couple of years before in
the author PhD thesis work (1984), a (rare) ground-breaking document because of its later
influence on other researchers works.
The model considered by these authors imposes windows on the pickup times of inbound requests
and on the delivery times of outbound requests. A maximum ride time, expressed as a linear
function of the direct ride time, is also imposed for each user.
The important studies by Jaw weren’t of course the first of its field; many scholars had intuitions
about the problem that were later re-used or exploited by their colleagues, making the researches
on this topic active and flowing. The author itself indicates some authors that have been
fundamental for his research path.
One of the most quoted studies has been delivered by Wilson et al. (1971, 1976, 1977) in connection
with the development of real-time algorithms for the Dial-A-Ride systems of Haddonfield, NJ, and
Rochester, NY.
The ADARTW “slice” derives some of its fundamental concepts (like building tours through
sequential insertion of customers and the general form of the objective function) from that work.
In parallel, a paper by Roy et al. (1983) appeared as Jaw paper was being completed and it also
uses similar concepts and solves essentially the same version of DARP. While the work are similar,
has been chosen to put under the microscope only the work by Jaw.
Also Hung et al. (1982) have been tackling the same problem but have adopted an entirely
different approach involving processing (in particular “scheduling” and “routing”) on one vehicle
at a time rather than all vehicles simultaneously, which is one of the main characteristics of this
26
ADARTW application.
Psaraftis (1983a) on the other hand has developed a dynamic programming algorithm for solving
the single-vehicle DARP optimally for a small number of customers in the presence of time
windows, followed by Solomon (1983), who later published an excellent review of the vehicle
routing problem (so not a pure DARP) with time-window constraints.
Numerous descriptions of DARP without time-window constraints can be found in Bodin et al.
(1983).
Other scholars who distinguished themselves in this field before (or during) Jaw’s studies are for
instance Hendrickson (1978) and Daganzo (1978) who have developed approximate models to
evaluate the performance of Dial-A-Ride systems. Also, Stein (1978a, 1978b) has presented a
probabilistic analysis of the problem, followed by Bodin and Sexton (1982); again, Psaraftis has
described an exact approach based on dynamic programming (1980) as well as several polynomial-
time heuristics (1983b, 1983~) for solving the single vehicle problem. After that, Jaw et al (1982),
proceeded on studying an approach to solving the multi-vehicle, advance-request DARP in the
absence of “hard” time-window constraints, using a three-step (grouping, clustering and routing)
algorithm.
Another good example of multi-vehicle Dynamic DARP has been provide by Madsen et al., in is
real case scenario of an elderly and disabled people focused transporter based in Copenhagen.
Users can specify a departure or arrival TW, but not both.
Not all the vehicles have the same capacity and are available at the same time and it is also taken
into consideration of a possible breakdown which would let them unusable. Request are not fixed
and arrive dynamically during the day; an important feature is about speeds, also considered to be
variable and not fixed.
3 An Algorithm for DARP
3.1 Introduction
The core of this thesis work will be the examination and the dissection of the main function of a
specific algorithm tailored to solve Dial-A-Ride problem with specific characteristics.
The history and development of the algorithm will be exposed, starting from the earlier studies
through the most recent software’s implementations.
27
The plural regarding the software is not a typo, since the researches surrounding this algorithm
have been translated into directs on-field applications during the years, in which the latter of those
has been the DARS, developed from the PTV Sistema.
DARS software has been developed by the Italian company Sistema, part of the German leading
group for transport software’s and traffic solutions PTV.
The entire numerical part of this thesis work has been treated by using it.
The roots of DARS must be searched through the pioneering work of Wilson et al and Jaw.
The latter especially has been an “early bird” researcher of the DAR problems and the following
solving algorithms. Starting from his 1984 PhD Thesis, Jaw presented an “heuristic algorithm for
DARP with soft time constraints”, to be more precise, a heuristic algorithm to solve Advanced
Dial-A-Ride problems with Time Windows (from now on we will refer to this algorithm also as
ADARTW).
The work has been carried on with a paper published a couple of years after that, which assumed a
wider importance and inspired many in the following years.
His work will be the first stop of a deeper analysis.
Based on Jaw et al. work, a research paper and the following software implementation has been
developed by professor Gentile and his fellow collaborator and student Claudio Catta.
This paper led to an algorithm which changed some of the previous hypothesis coming from Jaw,
in order to improve the solution output.
It could be applied to numerous situations without big abstractions or simplifications, which made
a good fit to interpret real world situations, as it will be later shown.
For ease, we will be referring to this implementation as DARP.
The latest incarnation of this studies has been the already mentioned DARS, which stretched some
characteristics and changed (or corrected) some previous hypothesis, making the new
implementation a faster, more modern tool to examine situations which may require a high
demand of computational power.
It is important to notice that so far the software is not available on the market and it is still in a
stage that could be defined as pre-beta, since it’s still missing a proper GUI and some key features
that cannot be ignored in aim of commercial purposes.
28
Each one of the mentioned part will be now presented on a deeper scale in order to be aware of the
research situation and its growth through the years, exposing strengths, weakness and general
principles of working.
A big part will be dedicated to the presentation of the insertion functions which, as will be clearer
going on, is the core of the algorithm way of solving.
3.2 Jaw Algorithm (1984-86)
3.2.1 Logic Notes
In his 1984 PhD Thesis and the later 1986 publication Jaw managed to build a precisely constructed
structure to a heuristic algorithm for a time-constrained version of the advance-request, multi-
vehicle, many-to-many Dial-A-Ride problem.
As already mentioned we will refer to this problem as ADARTW.
“Many-to-many” refers to the fact that each customer can have a distinct origin and destination,
while “advance” request means that all the requests are received well before the time of vehicle
dispatching.
The Time constraints (also mentioned as “Quality constraints”) consists of upper bounds on:
➢ The Amount of time by which pick-up or delivery of a customer can deviate from the
desired pick-up or delivery time
➢ The time that a customer can spend riding a vehicle
The “advance” is one of the characteristic that will be later changed in the development that will
be tackled later.
The algorithm uses a sequential insertion procedure to assign customers to vehicles and determine
a possible time schedule for pickup and deliveries for each of these.
The entire functioning is regulated by a “flexible” objective function which balances the cost of
providing service with the customers’ preferences for pick-up and delivery times as close as
possible to those requests.
29
As said, the algorithm has been originated from an 80s research which may seem overall outdated,
even thou it is still interesting for many reasons.
ADARTW addresses what is probably the most applicable and realistic version of the real-world
problem in a way that avoids excessive abstraction and simplifications, while emphasizing on
flexibility and convenience. This might seem obvious, but many modern algorithms and
applications tend to focus on different aspects, ignoring the operational aspects.
Considering resolutions of wider, more reality-attached problems in which speed counts as much
as precision, this algorithm seems to fit in nowadays applications.
Even in 1986 it was noted that the computation required to get high quality solution was low
compared to other system already working at that time.
It is easy to understand that with today’s improvement of computation power (and for the
immediate future) this tendency to use low computational resources would translate into the
chance of solving complex problems which were impossible to tackle years ago.
3.2.2 Problem Formalization and Operating Scenario
Time Windows have been nominated already and in this case their functions is obviously not
different from the average situations.
The Dial-A-Ride system for which the algorithm has been thought is defined by some important,
strong assumptions, which have been maintained for a large part in the new software
implementation we will later examine.
The assumptions are the following:
➢ The customers have the possibility to specify a desired pick up time (DPT) from an origin
or a desired delivery time (DDT) to their destination.
It is extremely important to notice that is impossible to specify both.
➢ Any customer who specified a DPT cannot be collected before that specific time.
➢ Any customer who specified a DDT cannot be delivered after that specific time.
30
➢ Given an average riding time (ART) for any client, it must not exceed a maximum riding
time (MRT). The MRT is computed based on the direct riding time (DRT) from an origin to
a destination, which represent the exact minimum riding time without stops in between of
O and D.
➢ The difference between the desired time (DT) of pickup or delivery and the actual time of
pickup or delivery, named deviation time (DV) must not be more than a set maximum.
The possibility for customers to choose their own PU o D time is certainly a big advantage,
although it is reasonable to expect a certain regularity in this choice, especially in specific part of
the day. For instance, it might be easier to find a greater amount of DDT in the morning because of
a mandatory time to start work; while at evening (Or night) this tendency could be reversed.
In a Dial-A-Ride service of this type a central part of the attention is reserved to the quality of
service.
To give a practical example: if a customer lives 15 minutes by car from a shopping centre and
requests a delivery at 10 AM, it is out of discussion that he shouldn’t be delivered at 8 AM, since
that would be a severe violation of his request. Also, his ride should be confined into a reasonable
time interval, so for example a 90 minutes trip would not be reasonable and is seen as terribly low
service.
The value of the MRT and the maximum deviation from the DT could be negotiated from time to
time between the service operator with any customer, basing this decision on the actual part of the
day the request is fitted in. Instead, an operator should decide to introduce a one-way maximum
deviation without taking any suggestion or request from the user about it (this method will be
later used during the tests).
The version of DARP solved by ADARTW can be then summarized as follows.
Given a list of N customers who specified a desired pickup (DPTi) or a delivery time (DDTi) and a
fleet of n vehicles, find an effective client allocation of customers among vehicles and an associated
time schedule of pickups and deliveries so that it results:
➢ For any customer:
ADTi – APTi ≤ MRTi
31
Where ADTi is the Actual delivery time for the request i and APTi is the Actual Pickup time
for the same request.
➢ For DPT customers only:
DPTi ≤ APTi ≤ DPTi + WSi
Where WSi is the time window extension for the pickup. In this case it is obviously possible to
get the Pickup after the desired time, while it may lead to a “malus” in terms of cost and it
mustn’t overcome the amount of the Time windows for any reasons.
➢ For DDT customers only:
DDTi - WSi ≤ ADTi ≤ DDTi
On the other hand, for deliveries the time window is set before the desired delivery time. As
for the pickup, the actual delivery happening before the DT would lead to a “malus” in terms
of costs.
Note that it will be later specified a measure of effectiveness.
It is also important to notice that it may prove infeasible to serve some of the N customers with the
given vehicle resources and this kind of service-quality constraints.
➢ It will be then assumed:
WSi = WS.
It might seem pointless, but it makes that particular quantity a constant so that the calculation
will be smoother.
➢ MRT is a function of the direct riding time DRT; Jaw used the current formula:
MRTi = A + 𝐵 × DRTi
With 𝐴 and B as user-specified constants (For example A = 5 mins and B = 1.5) as a given input
of the problem.
Other functional forms can be used to specify MRTi,, such as the one we will later see applied
and that takes the form of:
MRTi = 𝛼 × DRTi
32
The Table below shows the summary of the principal variables.
N Number of customers
m Number of available vehicles
DPTi (DDTi) Desired Pickip Time (Desired Delivery Time).
EPTi (EDTi) Earliest Pickup Time (Earliest Delivery time).
LPTi (LDTi) Latest Pickup Time (Latest Delivery Time).
APTi (ADTi) Actual Pickup Time.
DRTi Direct Riding Time (Interval needed by vehicle to go directly from O to D)
ARTi Actual Riding Time
D(x,y) Time to get from x to y
[+i | -i] Pickup (+) and Delivery (-) events
DVi Deviation time between desired time and actual time
WSi Maximum acceptable deviation between desired and actual time.
d Number of stops within a block
SLACKj Waiting time interval before the next stops block j
The last two variables, d and SLACK will need a deeper review, since are important concepts for
the DARP software and the new DARS as well (the structure has been maintained almost without
any differences in this case).
Some additional assumptions are needed and should be noted before diving into the algorithm
structure.
➢ Vehicle Capacities are assumed as finite and may not necessarily be the same for the entire
fleet.
➢ The Losing time for charging and unloading the customers (also known as Dwell time)
may be different from customer to customer and more than 0.
While it is sometimes easier to consider this time as null (or just neglectable), it might be often the
case to set a value higher than 0.
Jaw proposed to handle non-zero dwell times by adding them to a distance matrix in a way
consistent to the definition of APT and ADT. Of course, this changed on the latest implementation.
33
➢ The Vehicle is not allowed to idle when having customers on board.
This is a fundamental assumption for the logical construction of the problem. It is felt that such
idle periods would not be tolerated by Dial-A-Ride users.
In fact, this immediately translates into a real-service scenario: if a customer is scheduled to be
picked-up at 19.00 by a vehicle n, it should not stop and wait until it is about that time if the
vehicle already has other customers on board waiting to be delivered.
In general Jaw distinguish the vehicle activities in different periods:
➢ Available: the vehicle is on-service and available to take charge of requests for a certain
period, which may be the 8-hour work day. If not available (Non-Active), the vehicle
should not be considered for the service.
If the vehicle is available, it is useful to distinguish between Active and Idle intervals.
➢ Active: the vehicle is moving, so it has customers on board or at least some requests are
going to take charge of.
➢ Idle: the vehicle has no requests nor passenger on board, so it doesn’t move until a new
request is communicated to it. The stop may be done in a recharge station (introduced in
DARP implementation).
3.2.3 Algorithm Overview
As by definition by Jaw himself, ADARTW is a heuristic algorithm that processes ride requests
sequentially, inserting one customer at a time into the work-schedule of some vehicle until all ride
requests have been processed.
Two vital steps of the algorithm which must be overview for the sake of clarity are:
1. The algorithm searches for feasible insertions of customers into work-schedules
2. An optimization function it is used to find the best feasible solution for the insertion.
These two parts will be later described separately, as they are equally important and for the
algorithm construction and cannot be by-passed in their description to understand its philosophy.
34
Of course, the insertion of a customer into the work-schedule is considered feasible only if it does
not lead to violation of any service quality constraint for the newly assigned customer and, almost
more important, for any other customer already assigned.
The optimization step deals with minimizing the additional cost due to inserting the customer into
a vehicle’s work-schedule; the cost function used for this aim is a weighted sum of disutilities to
the system’s customers (like the excess of riding times and the deviations from the most desirable
pick-up and delivery times) as well as the cost known as “system’s costs”.
3.2.4 Processing of a generic customer
This version of the algorithm considers the problem already exploited above, which is N
customers for service and n available Dial-A-Ride vehicles.
ADARTW begins by indexing customers in the order of their EPT.
The algorithm then processes each customer in the list in sequence and assign each customer to a
vehicle until the list of customers is exhausted.
As said above, the generic version can be modified with other options for a more defined result.
➢ Customers can be indexed and processed according to criteria other than EPT.
For example, one can also process customers “backward” by ordering them according to their
LDT, with the customer having the largest LDT being processed first. Such alternative processing
orderings can be used to generate several alternative solutions.
➢ Instead of processing one customer at a time, the user can specify how many (yet
unassigned) customers should be considered in the first step.
For example, if the number 5 is specified, the top five (in terms of their EPT index) unassigned
customers will be considered on each occasion as candidates to be assigned next to a vehicle. It
should be emphasized that each of the candidates is considered separately in Step 1, so that in Step
2 the candidate (among the five, in our example) with the smallest COSTi would be assigned to
vehicle j*, while the remaining customers stay unassigned.
This hypothesis is provided for the purpose of improving the performance of the algorithm by
35
making it less “myopic”, to use Jaw’s very effective words. The reason is simple, since if the
opportunity is given to select among more than one customer for the assignment it might turn
better for the average cost, instead of the local-step cost. Of course, the downturn would be to
increase the number of computation and directly decrease the algorithm efficiency.
➢ If the user desires so, ADARTW will not reject any customers.
This condition would translate into assigning the customer to a vehicle that was not considered
available at the beginning, so it will join the already existing fleet.
This could be a vehicle/driver which is forced to do overtime for lack of other choices, so it might
be seen as an increased cost situation.
3.2.4.1 Feasible Insertions: search methods
This section will be dedicated to identifying feasible insertions of customers into vehicle work-
schedules.
A notion which plays an important role in this respect is the “Schedule Block”.
A schedule block is a continuous interval when the vehicle is active, between two successive
periods of vehicle slack time, so the moments in which the vehicle is Idle and waiting to start new
operations.
A schedule block always begins with a vehicle starting (possibly from a depot) on its way to pick
up a customer and ends either after the vehicle discharges its last customer on board or after the
vehicle returns to a depot. Associated with a schedule block is a “schedule sequence” indicating
the sequence of stops in the block, and a “time schedule” indicating the time when each stop is
scheduled to take place.
As obvious, the schedule block should necessarily start with a Pickup and finish with a Delivery.
Let’s suppose the next phase would be to examine whether an unassigned customer I can be
inserted into the work schedule of vehicle j. The objectives of the search for feasible insertions are:
I. To identify feasible sequences
This passage underlines the fact that it might not always be possible to insert request in any
36
possible combination, due to the different constraints the problem is subject to.
II. For each feasible sequence to find upper and lower bounds for APTi and ADTi, meaning
the bounds for the times when it is feasible to schedule pickup and delivery of customer i.
As already explained, the Pickup and Delivery bounds are drivers for the entire scheduling
problem, since their task is to ensure that the problem is going to respect any constraint while
searching for the best possible solution.
Figure 3-1 - Standard Schedule Block representation
The algorithm examines all possible schedule sequences associated with each schedule block for
vehicle j.
It is noticed quickly that if there are d stops in the schedule block already, the number of possible
schedule sequences that involve the insertion of a new customer are:
(𝑑 + 2)(𝑑 + 1)
2
Of course, the obvious constraint of “pickups before deliveries” must be maintained.
It is important to notice that in addition to inserting customer i into one of the already existing
schedule blocks of any vehicle j, ADARTW will consider creating an entirely new schedule block
Slack
time
Planned Pu/D
Block first
instant
Instant in which vehicle
starts to move
Block last instant
(vehicle will return to
idle situation after this)
37
for vehicle j to accommodate customer i. For example, the first customer ever assigned to a vehicle
will obviously always create a new schedule block. Such new schedule blocks are added to the list
of existing schedule blocks to which ADARTW attempts to add new customers through the
insertion procedure.
The purpose of this insertion in the schedule block is to facilitate ADARTW on its research and to
make it more efficient, which is fundamental while dealing with large-scale problems.
The procedure involves the creation of two different time windows as follows below.
Figure 3-2 - Delivery Time window
Figure 3-3 - Pickup Time Window
TWIN DRT ( – 1) DRT
+
TWIN
DELIVERY
TIME ZONE
P D
time
EPT LPT EDT LDT
MRT = · DRT
TWIN
DRT ( – 1) DRT
+
TWIN
PICKUP
TIME ZONE
P D
time
EPT LPT EDT LDT
MRT = · DRT
38
For DPT kind of customers, we define:
EPTi = DPTi (3.2.5)
LPTi = EPTi + WSi (3.2.6)
EDTi = EPTi + DRTi (3.2.7)
LDTi = LPTi + MRTi (3.2.8)
Similarly, for each DDT kind of customer we define:
LDTi = DDTi (3.2.9)
EDTi = DDTi - WSi (3.2.10)
LPTi = LDTi - DRTi (3.2.11)
EPTi = EDTi - MRTi (3.2.12)
For any customer i, whether DPT or DDT kind, a set of necessary but not sufficient conditions for
feasibility is then provided by the followings:
EPTi ≤ APTi ≤ LPTi (3.2.13)
EDTi ≤ ADTi ≤ LDTi (3.2.14)
It is easy to see that (3.2.13) and (3.2.14) are not sufficient because it is possible that APTi and ADTi
satisfy them, but the time is greater than MRTi.
Of course, it is also mandatory (if not trivial) that LDTi must be higher than EDTi.
The quantities EPTi, LPTi, EDTi, and LDTi, are computed from the equations above and define
“fixes” on the time axis within which the customer must be picked up and delivered. To
understand the value of these fixes it might help to return at the problem of checking the feasibility
of inserting customer i into a schedule block (p) for vehicle j.
Indexing the successive stops on the schedule sequence with the subscript 𝛼 = 1, 2, … , 𝑑.
The (3.2.13) and (3.2.14) give us an upper and lower bound for each element in the time schedule
associated with our schedule block.
39
It is convenient to drop the indication of whether a particular stop on the schedule block is a pick-
up or a delivery and use ETα , ATα and LTα to denote earliest, actual (so the scheduled one) and
latest time, respectively, for stop α. This will make it possible to avoid the specification of the stop
typology (Pick-up or Delivery).
ADARTW is programmed to compute and store four statistics for each stop α on each schedule
block, defined as follows:
BUPα = min[ 𝑚𝑖𝑛1≤𝑙≤𝛼 (𝐴𝑇𝑙 − 𝐸𝑇𝑙) , 𝑆𝐾𝑇𝛼]
BDOWNα = [ 𝑚𝑖𝑛1≤𝑙≤𝛼 (𝐿𝑇𝑙 − 𝐴𝑇𝑙)]
AUPα = [ 𝑚𝑖𝑛𝛼≤𝑙≤𝑑 (𝐴𝑇𝑙 − 𝐸𝑇𝑙)]
ADOWNα = min [ 𝑚𝑖𝑛𝛼≤𝑙≤𝑑 (𝐿𝑇𝑙 − 𝐴𝑇𝑙) , 𝑆𝐾𝑇𝑞]
SKTp and SKTq denote, respectively, the duration of the slack period immediately preceding and
immediately following the schedule block in question.
There is a real intuitive meaning associated with the four quantities defined by these last equations
above.
Specifically, BUPα (BDOWNα) represents the maximum amount of time by which every stop
preceding but not including stop α + 1 can be advanced (delayed) without violating the time-
window constraints.
Similarly, AUPα (ADOWNα) represents the maximum amount of time by which every stop
following but not including stop α - 1 can be advanced (delayed).
Essentially, the quantities BUP, BDOWN, AUP and ADOWN indicate by how much, at most, each
segment of a schedule block can be displaced to accommodate (pick up, deliver, or both) an
additional customer.
As an example, in a situation where an attempt is made to insert the pick-up of customer i between
the second and third stop of a schedule-block containing four stops, the extra time required to visit
the additional stop is called Detour.
If Detour ≤ BUP2 + ADOWN3, then it is feasible to insert a pickup in the schedule-block at the point
indicated without violating any time-windows for the customers already in the schedule-block.
Should this be the case, it is then necessary to check whether it is also feasible to insert the delivery,
40
taking into consideration the fact that an extra amount of time equal to Detour has already been
spent to pick up customer i. This second check can also be performed using the quantities, BUP,
BDOWN, AUP and ADOWN. Finally, once it is determined that it is feasible, as far as the time-
window constraints are concerned, to insert customer i in a way within a schedule-block, a check
must be performed to be sure that no maximum-ride-time constraints are violated for the newly
inserted customer and for the customers already in the schedule block. This operation is done by
scanning through the list of these customers and comparing the respective actual ride-times and
maximum ride-times.
Figure 3-4 - Allowed left and right shifts
Planned
New Pu/D after
Needed left and right
shift to absorb the Detour
caused by the new
insertion
When more than one stop have to be shifted to
absorb the detour, the shifting limit is the
minimum between all the possible bounds!
41
ADARTW handles four different possibilities which account for the total combination mentioned
earlier. The “feasibilities” are numbered as follows:
I. Both the Pick-Up and the delivery of customer i are inserted at the end of the last schedule
block, so that the result would be those two stops would turn into the last two of the block.
II. Both the pick-up and the delivery of customer i are inserted between two consecutive stops
on the schedule-block
III. The pick-up of customer i takes place somewhere within the schedule block, while his
delivery is inserted at the end of the work-schedule
IV. The pick-up and delivery of customer i are separated by at least one other stop and the
delivery of i is not the last stop on the expanded work schedule
Figure 3-5 shows the graphical representations of these insertions.
The (commented) schemes representing the logical workflow of each feasibility will be presented
later, on the paragraph talking about DARS and on the appendix at the end. The reason for this
choice is that the logical of the insertions has been kept almost the same by later applications.
42
I. Feasibility I
Number of possible insertions = 1 (at the end of the block only).
II. Feasibility II
Number of possible insertions = N (where N is the number of stops within the block)
III. Feasibility III
Number of possible insertions = N
IV. Feasibility IV
Number of possible insertions = N (N-1)/2
Figure 3-5 -Possible Feasibility Insertions
43
3.2.4.2 Optimization Procedure
To select among all feasible insertions of customer i into the work-schedules of the available
vehicles, ADARTW uses an objective function designed to evaluate the incremental cost of each
insertion.
This is taken to be a weighted sum of disutility to the system’s customers and of operator costs;
this last element is measured in terms of consumption of available resources (just like vehicles).
Assuming that it is feasible to insert customer i into the work-schedule of vehicle j, then the
incremental disutility of that insertion to the system’s customers consists of the sum of two parts:
the disutility to customer i (the customer being assigned to a vehicle) and the additional disutility
suffered by all other customers already assigned to that vehicle because of the insertion of
customer i.
The disutility to customer i is given by:
𝐷𝑈𝑖 = 𝐷𝑈𝑖𝑑 + 𝐷𝑈𝑖
′
Where 𝐷𝑈𝑖𝑑 = Disutility due to deviation from the most desired time
𝐷𝑈𝑖𝑑 = 𝐶1𝑥𝑖 + 𝐶2𝑥𝑖
2 0 ≤ 𝑥𝑖 ≤ 𝑊𝑆
And 𝐷𝑈𝑖′ = Disutility due to excess riding time
𝐷𝑈𝑖′ = 𝐶3𝑦𝑖 + 𝐶4𝑦𝑖
2 0 ≤ 𝑦𝑖 ≤ 𝑀𝑅𝑇𝑖
C1 , C2 , C3 and C4 are user specified constraints.
Because of the particular meaning and structure of the function, the terms can be translated into
calibrated Value of Time coefficients, so that the function would better describe the disutility
originated by the time loss. By varying those, a lot of different behaviour can be represented,
including assigning value of zero.
On the other hand:
𝑥𝑖 = {𝐴𝑃𝑇𝑖 − 𝐷𝑃𝑇𝑖 𝑓𝑜𝑟 𝐷𝑃𝑇 𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟𝑠𝐷𝐷𝑇𝑖 − 𝐴𝐷𝑇𝑖 𝑓𝑜𝑟 𝐷𝐷𝑇 𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟𝑠
}
44
And:
𝑦𝑖 = 𝐴𝑅𝑇𝑖 − 𝐷𝑅𝑇𝑖
The disutility to other customers, which is the second part of the disutility, is given by:
𝐷𝑈𝑖0 = ∑ (𝐷𝑈𝑘
𝑁𝐸𝑊 − 𝐷𝑈𝑘𝑂𝐿𝐷)
𝑘 𝑜𝑛 𝑗
Where 𝐷𝑈𝑘𝑁𝐸𝑊 and 𝐷𝑈𝑘
𝑂𝐿𝐷 are, respectively, the disutilities to customer k after and before insertion
of customer i into the schedule of vehicle j.
The summation is computed over all customers k who were already assigned to vehicle j prior to
the assignment of customer i.
The incremental cost 𝑉𝐶𝑖 referred to the system operator due to inserting customer i into the work-
schedule of some vehicle is quantified by an objective function (which Jaw defines “unusual”).
𝑉𝐶𝑖 = 𝐶5𝑧𝑖 + 𝐶6𝑤𝑖 + 𝑈𝑖(𝐶7𝑧𝑖 + 𝐶8𝑤𝑖)
Where 𝐶5 , 𝐶6 , 𝐶7 and 𝐶8 are externally set constants, 𝑧𝑖 is the additional active vehicle time
required to serve the customer i, 𝑤𝑖 is the change in vehicle slack time due to the insertion and 𝑈𝑖 is
an indicator of system workload defined as:
𝑈𝑖 = (𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑦𝑠𝑡𝑒𝑚 𝑐𝑢𝑠𝑡𝑜𝑚𝑒𝑟𝑠 𝑖𝑛 [𝐸𝑃𝑇𝑖 − 𝑇𝑎 , 𝐸𝑃𝑇𝑖 + 𝑇𝑏])
(𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑣𝑒ℎ𝑖𝑐𝑙𝑒𝑠 𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 𝑖𝑛 [𝐸𝑃𝑇𝑖 − 𝑇𝑎 , 𝐸𝑃𝑇𝑖 + 𝑇𝑏])
The equation below introduces the terms 𝑇𝑎 and 𝑇𝑏, which are externally specified constants.
Jaw gives the following example to better understand the meaning of these.
For instance, if 𝑇𝑎 = 𝑇𝑏 = 60 𝑚𝑖𝑛𝑢𝑡𝑒𝑠 , 𝑈𝑖 is equal to the ratio of the number of customers
demanding service to the available number of vehicles during the two-hour time period that has
the earliest pick-up time of customer i as its midpoint.
Obviously 𝑈𝑖 is a measure of the system’s load, and will be larger during periods of heavy
demand.
During heavy-demand periods, the objective function gives an higher importance to system’s
operator costs, more than in low-demand periods. The reason is quite simple to understand, since
during periods of high utilization the “vehicle resources” are scarcer and it is fundamental to use it
properly and efficiently.
45
Some considerations may help to clarify the problem.
a) The change in vehicle slack time may be positive or negative.
The latter takes place when the original slack is partly reduced because of a new insertion, since
part of the time earned by the slack is given to compensate the detour.
On contrary, it will be positive if, to serve a new customer i, an additional vehicle slack time must
be created. This situation happens when if a whole new schedule block is created to serve
customer i.
b) By looking at practice, the cost per unit of time of a vehicle in the “active” state is greater
than in “slack” state ( because, for instance, there is no fuel consumption).
That said, it should result 𝐶5 ≥ 𝐶6 and 𝐶7 ≥ 𝐶8.
3.2.4.3 Optimization procedure summary
Consider customer i who is to be inserted into the work-schedule of one of m available vehicles.
Assume that for each vehicle j (j = 1, 2, … , m) all feasible sequences for inserting customer i into
the work schedule of j have been identified in the manner outlined before.
To select the optimum insertion a sequence of three steps is used:
I. For every feasible sequence pertaining to vehicle j, find a time schedule (including pickup and
delivery times) that minimizes incremental cost 𝐷𝑈𝑖 + 𝑉𝐶𝑖 .
This requires shifting the feasible time schedule associated with each feasible sequence within
its bounds.
II. Choose the one sequence among those examined above which results in the smallest
incremental cost. This smallest incremental cost id 𝐶𝑂𝑆𝑇𝑗, the additional cost associated with
inserting customer i into the work-shcedule of vehicle j.
III. Eventually assign a customer i to a vehicle 𝑗∗ such that 𝐶𝑂𝑆𝑇𝑗∗ ≤ 𝐶𝑂𝑆𝑇𝑗 for all j (j = 1,2,…m)
46
3.3 DARP (2004)
DARP algorithm has been developed by professor Guido Gentile and the graduating student
Claudio Catta at Sapienza University. The publication presenting the algorithm and the later
software implementation is from year 2004.
As already explained, the functions and structure of DARP is a bridge between the previous work
by Jaw and the later DARS implementation.
To deconstruct the meaning of the phrase above, the software itself has been the foundation on
which the more recent, modern DARS has been developed.
In fact, DARP already presented a good part of the logical workflow that has been later transferred
to the new version. The central optimization heuristic algorithm is actually a refreshed version of
the ADARTW developed by Jaw. The re-adaptation has been made by the developers in order to
maintain the spirit of the previous algorithm and to adapt on new structures.
The “spirit” is in fact the extremely adaptable algorithm structure, which allows to treat complex
problems faster than many (more modern) formulations; also, it is more focused about obtaining
an overall optimal result.
As for the Jaw formulation, every Vehicle is scheduled to do a certain sequence of stops. A good
difference from that version is that sequences are updated while the time goes on with new
requests which are given to the system throughout time.
These new requests are elaborated by the algorithm and processed with a criterion which is
decided a-priori while setting up the software simulation.
Another difference is the possibility to set the software on elaborating only requests that arrived
before a certain time (advanced requests, as for Jaw) or in order of complexity; this two-way
possibility is given by the offline= 0/1 input in the options tab.
3.3.1 Software Implementation Structure
DARP inputs and outputs are delivered through tables.
As specified in the manual, any data must be specified, even if it is not used in a case.
Related tables are present for any “object” in the software and are redacted in .dat format.
47
For instance, there are different tabs to describe vehicles, nodes, arcs and charges.
This last type is referred to the possibility of recharging the vehicles, since as we’ll see later, the
energetic problem is taken into consideration in the results.
To give a hint of the tables format it might help to report the one which describes the nodes in the
network.
Field Data Type Description unit
ID 1 integer K Node ID ID
long Real Longitude °
lat real Latitude °
Table 2 - DARP Data Table Nodes.dat
An interesting aspect of the DARP is its possibility to choose both the online version and the
offline version, which basically translates to the chance of examining a problem with an advanced
set of requests or a set which is created during a certain interval on real-time conditions.
The table in charge of designing the constraints and moreover the general characteristics of a
chosen test run is the options.dat.
After the run, the results are visualized on tables as well.
Because of its functioning structure, the problem can only give certain data. To better distinguish
the outputs, those are divided into aggregated, routes related and services.
3.3.2 New Implementations
Besides all the constraints presented in the paragraphs above, the algorithm allows to tackle some
other questions.
It is important to notice that all the specifications exposed are optional and can be selected and
neglected as well at the beginning of the session.
Briefly, the first problem is about the work shifts of vehicles.
The needing of constraining work times into shifts is given by the fact that some operational
needing exists, whom most of the transport systems need to respect.
48
For example:
➢ Trips should stay under a pre-set maximum
➢ Any trip should begin and return to a deposit
➢ Multiple trips should be performed in the same day
The second problem is the energetic one. To better explain, it might be useful to think that the
algorithm itself has been projected and presented as using an electric fleet.
Of course, beside of the advantages, the system would present some typical characteristics, such
as:
➢ Vehicles with a limited energetic capacity
➢ Linear electrical consumption with the number of served customers
➢ Extreme needing of setting up recharge stations
The third specification takes into consideration the possibility for vehicle to have multiple capacity.
This means for instance to be capable of taking on board at least two different types of customers
(and/or freights).
Regarding the insertions there is an addition as well. Catta illustrates the procedure which is done
prior to the actual insertion tries and the used sequence to take into consideration both vehicles
and requests.
The last (but not least) specification it is actually the most important one, since it is one of the pillar
around which DARS it is later been developed on.
This spec is taking into consideration the possibility for the algorithm to work on immediate
requests. Intuitively, this feature gives the possibility to the algorithm to be used with an on-line
function, which permits to update the vehicles paths while receiving new requests.
The different aspects will be now exposed a bit more deeply.
49
3.3.2.1 Work-Shifts
As already said, it is useful to distinguish between availability, active periods and inactive periods.
An available vehicle might be active (carrying customers, moving to a pick-up or drop point,
getting back to the deposit) or idle.
To determine the in-active periods of any vehicle, the algorithm build work-shifts with the
duration time as an input; like that, work-shifts are an additional constraint, adding to the
maximum deviation from desired time and maximum riding time.
Any time a new vehicle gets activated (or a new client is inserted), it is defined at the same time the
starting instant of that work shift, coincident to the instant from which the vehicle leaves the
deposit and the last work instant by the duration of the shift itself. The vehicle will be later
available again after a certain period after the end of the last shift (as before, this is still an input
data).
The successive insertions are infeasible if determine an hour to deposit return which is higher than
the last work-shift instant.
The insertion which does not violate the work-shift may belong to two main different types:
➢ Insertion which does not modify the departure time from the deposit
➢ Insertions which provoke a shifting from the starting time
First type insertion does not create any problem, while the second type insertions are infeasible if,
given PS as the quantity the starting time should be shifted, it results that last stop time of the
current work-schedule plus time necessary to return at the deposit is higher than the last work-
shift time minus PS.
3.3.2.2 Energy Problem 3
A new client insertion is made between two recharge stations (A and B). Initially the two stops
coincide with the starting and return deposit, and the related times are the starting and ending
time of availability for each vehicle.
Anytime a new customer is inserted in a new vehicle, the energy status of the recharge stations is
50
checked. If in one of these stops (for instance B) the energy consumption is higher than a certain
threshold, a procedure is re-called to insert a recharge stations between the stops A and B in which
the violation happened.
This procedure works as follows: the first try is to insert the new recharge stop right before the
station in which the threshold is being violated (B); if that would not be possible, slack-periods
between A and B are checked. Starting from B to A, is a Slack whom duration is enough so that is
possible to insert a Detour at the closest recharge station plus the necessary time to recharge and if
the insertion of the new internal recharge of that slack-period is efficient (meaning that B energetic
state is under the threshold), a new recharge is inserted; otherwise the following slack-period is
checked.
If none of the trials has been possible, the following insertions between A and B are infeasible.
3.3.2.3 Multiple Capacity
The requests may be composed by several customers, not necessarily equal to 1.
The algorithm allows to handle two types of passengers, such as disabled and non-disabled. The
consequence is two types of capacity inside vehicles.
From that, it follows that the procedure which is assigned to determine whether the possible
insertions of the generic customer i to vehicle j is feasible or not, on every trial is started a check
whom objective is to control that every capacity is not violated.
3.3.2.4 On-Line Function
This version of the algorithm is characterized by the fact that requests are processed one after
another, ordering them basing on their call-time.
The big difference from the offline version lays in the definition of quantities of which the single
stops may be shifted forward or back, to allow the insertions of new customers.
Anytime a call is taken (so a customer is processed) these quantities are updated and computed
again, taking into consideration that no modifications can be done on the events happened before
the actual time or still happening.
51
For instance, the pick-up of a customer i (+i) may not happen between two stops +k and +m not
only if the pick-up time of k is minor than actual time (which is now), but also if, even though the
k pick-up is still not happened, by the actual time the vehicle already left the stop before +k and it
is already on its path to k.
This rule it is also valid for any other type of event, not only insertions. So, for example recharges
or an entire stops block.
As already mentioned, this last problem has a strong importance also on today’s version of DARS.
The same hypothesis is present on the software today.
3.4 DARS
The latest stage of the software has become what is currently known as DARS, created inside the
Italian branch of PTV Group SISTeMa, based in Rome. For ease, we will also refer sometimes to the
software as PTVD, even though it is not an official PTV product.
So far, this has been the last stage of development for the software made to solve Dial-A-Ride
problems. Although the amount of work done on this last implementation have been a lot, the
product has to be considered on a beta stage of its development.
The software path is far from being completed. It is still under consideration for future
betterments, whom aim would be to implement other features that would help to describe better
real-world solutions and provide some better shaped results.
The software already pushed some boundaries from its predecessors and helped update the whole
structure to modern situation, in which the connection to real-time world and obvious seconds-by-
seconds changes cannot be ignored.
Besides the internal changes in terms of coding structure, which led for example to a modular
code, the software shows some logical detachments and betterments.
The later paragraphs will be dedicated to highlight the differences (and improvements) of this
latest version, helping the explanation with schemes, figures and programming hints.
52
3.4.1 Main Characteristics, Input loading and simulation outcomes
Many of the characteristics such as blocks, slack times, shifts and in general the whole
overstructured logic presented in the precedent implementations are still valid on their
“philosophy”, so there won’t be any need to define any of these elements again if not strictly
necessary.
As imaginable, the way inputs are loaded onto the software and given to the algorithm has pretty
much changed to the respect of the previous applications, remembering that the first one is from
the eighties and the latter is 15 years old still.
The software has been programmed using VB.NET language.
After launching the software, a command line console is recalled, in which it is possible to set the
right input for the simulation.
Figure 3-6 - Command Line (Data Source Tab)
The first row indicates the source for the map modelling on which the simulation will be based.
In this case, the example shows the Turin city model (which will be later used for simulations as
well). It is important to notice that the software has been built taking into consideration a full
compatibility with PTV softwares, such as Visum and Optima.
Also in this case, Turin City model has been prepared by SISTeMA modellers using PTV Visum.
On the upper left, the tabs indicate the different types of data the user can setup.
It might be a good idea to focus on the Input tab to have a better understanding of the problem
construction path.
53
Figure 3-7 Command Line (Input Tab)
A lot of fundamental parameters can be set by this tab.
➢ Vehicles_Path : follows the path to the folder containing the file in which are stored the
vehicles fleet information.
This file is generated by a Python script, in which it is possible to set number of vehicles and the
distribution of the fleet itself through the bounding box. This will be later treated during the
simulations.
➢ Vehicle_search_distance : this function sets the radius for vehicle searching (see the Vehicle
search paragraph below)
➢ Idle_cost, Activation_Cost, C1,..4 : allows to set parameters that will be taken into
consideration while calculating the Cost function
➢ Use_Graph_Info : activate the street graph so that the distance would not be calculated only
by geometrical methods but through the use of an A*.
➢ Export_to_DB : allows to dump data about vehicle fleet, requests distribution and paths
onto a database.
54
This last option it is very helpful because of its interaction with softwares like qGIS.
qGis gives an important graphical conscience of the distribution inside the problem area and it is
quicker, more efficient way to understand if certain hypothesis is correct.
The layer originated by this interaction are visible later while presenting simulations.
Even though a row for requests exists (just like for vehicles), the latest method to send those inside
the software is by running a Python script which, during the whole time of the simulation, sends
real-time requests.
This script (colloquially known as “shooter”) permits to shape the requests distribution and timing
to better simulate a precise situation.
In fact, it doesn’t only allows to distribute requests following a given probability function, but also
the interval between a requests and its following, the Time Windows, the time span between the
request reception and its Call Time and other features.
The main characteristics would be later exploited, as for many other elements, during the test
chapter.
Every run of the software creates a LOG file (.txt extension), in which every step of the simulation
is registered and written. The information of the log is printed so that it is possible to collect the
needed data and to obtain a successful analysis.
A more complex simulation brings to a bigger LOG file, which means it would be impossible to
examine only by scrolling and reading.
The outputs of the simulation are mined through the LOG file by using, again, a Python Script.
This helps considering only the important part of any string and plot part of the data into tables
which allows a better reading of the outputs.
55
Figure 3-8 - Simulation run outcome
Figure 3-9 - Log Analyser with a printed plot
3.4.2 Street Graph and Dynamicity
On the previous versions of the software the distances were computed geometrically without
taking into considerations the actual paths that are present on a normal urban (or any real-world)
scenario (ADARTW by Jaw). Alternatively, there was the possibility to use travel time matrices for
56
any possible path (DARP). These computations were stuck, by definition, to a static situation of the
system overall.
The last implementation of PTVD on the other hand gives the possibility to consider a street graph;
not just simpler versions made of nodes and arcs, but more heavy and complex ones.
To be more specific, PTVD does communicate with software like PTV Visum.
This addition allows our simulation to fit better in a real-world scenario, since Visum (and similar
software) allows the modeler to re-create entire cities transport systems. So, the street graph on
which the simulation will be based can use all the possible data about lanes and street to deliver a
better output.
Implementing a graph into the simulation means that computing the best path from an origin to a
destination is not something that can be done with a simple geometric operation anymore.
In fact, it is necessary to implement a path finding algorithm capable of exploit the most
advantageous solution in terms of costs.
PTVD uses an A* algorithm to provide this solution.
Beside the graph improvement, the software accounts the traffic states at different times of the day.
That means the software is in fact dynamic, meaning that the travel times between different
locations won’t be the same throughout the day.
The fact that travel times are not steady highlights that costs for a certain path varies following the
congestions fluctuations.
There is no need of any travel-time matrix: the pathfinding algorithm provides the shortest path
after updating the traffic state, and this calculation allows the system to be consequently dynamic.
57
Scheme 1 - Traffic states dynamic workflow
3.4.3 Insertions
3.4.3.1 Reduction Check
As comprehensible, insertions are indeed one of the main pillar of the algorithm.
The way these are handled assure that the software can find a good solution without spending too
much time on calculations and without wasting computational power.
As seen on Jaw, the insertion procedure relies on a sequential examination of blocks, stops upper
and lower bounds and rigid shifts of scheduled stops (and blocks), with the aim to find the “right”
couple in which insert the new requests.
The DARP implementation used to follow a sequential procedure starting from the vehicles (which
will be all selected) and their internal block schedule.
Next Request (PU o D)
Travel time to compute for insertion
Update Traffic Situation
A* Path Finding alorithm computes the best solution based on current
situation
Insertions tries and final cost cumputation
58
The first step would be to get a control over the possibility to actual try the insertion given the
current time.
To give a better explanation, the software performs a check over the Pickup (or Delivery) desired
time and confronts this value with the first instant of the first block for that particular schedule.
If Desired time > First block instant , the block is not taken into consideration (because it is too late
to insert in a block which already begun its operations) and the software start from the next block.
After doing the whole insertion procedure to find the best spot to insert (if one exists) in that
particular block, the software goes to the next block.
This sub procedure ends once the block are all examined and the insertion taken is the one with
the minimum cost between all the insertions performed.
If a feasible insertion is not found, that vehicle won’t be used for the requests, and the software
would then examine the following vehicle starting the procedure once again.
On the other hand, PTVD works following another logical workflow.
As explained on the Vehicle fleet paragraph, first reduction is made to the vehicle taken into
consideration before even starting the insertion tries.
After this first cut, the vehicles left are inspected in their schedules by the functions which have the
scope to sequentially consider the stops (by couple and not singularly, since the aim is to insert
between those) and find the ones candidate to actually “host” a pickup or a delivery.
This is made by checking whether the upper and lower bounds of every couple is fine with the
current request or not, so if they can be shifted and have enough room for another stop between
them.
After these passages, the survivor stops are “chewed” into the insertion procedure which leads to
the feasibility tries right after the routine checks such as capacity.
3.4.3.2 Feasibility Tries
The 4 ways through which a new request is inserted in the schedule are invariant from the
ADARTW and DARP implementations.
In fact, the logic schemes presented by Jaw for his ADARTW are respected pretty much in PTVD.
59
Figure 3-10 - Feasibility II Logical workflow
60
A commented scheme is presented for the logical workflow of the second type of feasibility for
insertions (Feasibility_II), in which the algorithm tries to insert Pick-Up and Delivery consecutively
between two stops of the block.
The main passages are enumerated and explained as follows.
(1) The first function to be recalled inside the feasibility itself is “DsTime”, which is defined as:
𝐷𝑠𝑇𝑖𝑚𝑒 = 𝑇𝑟𝑖𝑎𝑙 𝑏𝑙𝑜𝑐𝑘 𝑓𝑖𝑟𝑠𝑡 𝑖𝑛𝑠𝑡𝑎𝑛𝑡 − 𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝐶𝑎𝑙𝑙 𝑡𝑖𝑚𝑒
if the insertion is tried is before the first stop of the block, or:
𝐷𝑠𝑇𝑖𝑚𝑒 = 𝑆𝑡𝑜𝑝 𝑏𝑒𝑓𝑜𝑟𝑒 𝑃𝑖𝑐𝑘𝑢𝑝 𝑖𝑛𝑠𝑡𝑎𝑛𝑡 − 𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝐶𝑎𝑙𝑙 𝑡𝑖𝑚𝑒
if not (so if it is tried on any successive stop within the block).
This case would cover the “regular” insertion in the middle of the block.
One of the reasons for this choice is the fact that so far the software has been programmed to
skip the insertion at the beginning of the block, although the code itself still holds the
possibility to do so.
The trial block is of course the block in which the software is trying the insertion.
Given the first case and that quantity, the software checks if:
𝑑𝑠𝑡𝑖𝑚𝑒 < 0
If so, the block is immediately excluded, because the insertion would not be feasible anyway on
that particular block, meaning that the vehicle begun Pickup and Deliveries operations
already.
Figure 3-11 – Call Time representation
Slack time
Call time
61
In this case DsTime would be negative and impossible to dissipate with slack time.
On the other hand, if the quantity results to be more than 0, the call time happens to be in the
middle of the slack time (or before the block first instant), which allows the software to at least
try an insertion.
(2) This type of feasibility tries to insert between a certain couple of stops, because of that there is
the needing to calculate the possible Detour.
Figure 3-12 - Detour for an insertion between K and K+1
The image clearly shows the two possible stops which create the needed space to fit in the (K, K+ 1)
stops couple. Of course, the travel time between the stops is now higher than the previous
situation; the detour must be amortized shifting the other schedule stops of the block.
(3) As follows from the previous step, this check controls if the Detour is higher than the possible
shift of the previous and/or following stops.
In fact, the function controls if the both on the left and on the right it is possible to move the
stops enough to “accommodate” the generated Detour.
Of course, when found impossible, the software ends the procedure and goes on to another
stop couple or block.
As already noticed, the check on stops upper and lower bounds is performed even before
applying the insertion procedure.
Note that the software is programmed to try an insertion before the first stop of the block as
well. In this case the software won’t take the BUP but the slack time before the block instead.
(4) After controlling if the possible right shift is bigger than the expected detour or not, a decision
is made.
If bigger, the Detour must be absorbed shifting both the right stops (the stops after the
K P D K+1
62
requested one) and left stops (the stops before the requested one).
If smaller, only the right stops are shifted, leaving the stops before fixed.
(5) The actual time for Pick Up (or delivery on the right side) has respect the Earliest and Latest
Pickup times. The example will prosecute taking into consideration the Pickup.
In case of an actual pickup time which is minor (so earlier) than the Earliest time, another shift
is needed to fill this time delta.
In this example, the needed shift would be two minutes.
(6) These steps check if the needed shift for the stops can be absorbed by shifting of quantity
which has to take into the account the shift already done for amortizing the Detour.
If this other shift it is not possible because it’s too big, then the whole insertion would result
unfeasible and the procedure terminates.
Else, the quantities are shifted and, since we are still talking of a Pickup, delayed of the
necessary amount.
(7) The last passages have to value the Optimal Shift and the additional costs.
The Optimal shift is a function recalled finding the best possible solution to harmonize the
right shift to make everything feasible and at the same time keep the costs as low as possible.
It can be actually seen (as it is indeed) a procedure to find the minimum value of the cost
function. This is examined more in depth, along with the additional cost in the “Cost Function”
paragraph.
These last phases conclude the insertion process for a Feasibility.
This process is made for any possible feasibility. While doing this, a function of the software
keeps track of the minimum found after each try.
Actual Time for Pickup
Es: (19.03)
Earliest Time for Pickup
Es: (10.05)
63
At the end of the tries, the overall minimum is then computed and inserted as the best solution
for the request.
The opposite and unlucky case of finding no possible insertions at any cost would give a
“failed” insertion result on the Log file.
A scheme for any Feasibility is presented in the Appendix section with a brief legend to
recognize the parameters inside the scheme.
3.4.4 Requests
As underlined many times, one of the greatest limit for the Jaw Algorithm was to work with
Advance requests only, originating the name ADARTW.
The problem has been already tackled by the Online Function of DARP, which was a “switch” that
could be turned on as a plug in for the working algorithm.
The PTVD has been built specifically to take into consideration real-time or quasi real-time
requests only. Note that requests are processed one after another and there is no option to consider
small groups of it at any passage as thought by Jaw.
These requests are pushed inside the algorithm for evaluation by a python script (also known as
Shooter), which generates requests once given some base parameters.
Some of the requests characteristics the Shooter can control are:
1) Request Distribution along the study area
The script regulates the distribution of the function by using a multivariate Gaussian function,
whom means are given by:
Mean 1: [ (1− 𝛼)∗(𝑀𝑎𝑥 𝑋+min 𝑋)
2+ 𝛼 ∗ 𝑀𝑎𝑥 𝑋 ;
(1− 𝛼)∗(𝑀𝑎𝑥 𝑌+min 𝑌)
2+ 𝛼 ∗ min Y]
Mean 2: [ (1− 𝛼)∗(𝑀𝑎𝑥 𝑋+min 𝑋)
2+ 𝛼 ∗ 𝑚𝑖𝑛 𝑋 ;
(1− 𝛼)∗(𝑀𝑎𝑥 𝑌+min 𝑌)
2+ 𝛼 ∗ Max Y]
Where α is a constant introduced to give different shapes to the distribution, while X and Y
represents the coordinates of the study area.
64
2) The passengers number
These are generated following a proportion, so for example it is possible to decide for 2,3 or 4
passengers requests a proportion of (0.1 , 0.8, 0.1), meaning an 80 % of the requests should satisfy 3
passengers.
3) Maximum distance between Pick-up and Delivery
4) Time span between Call Time and Desired Time
This last point is what determines the “degree of real-time” on very request. In fact, this last option
is translated to the possibility to decide whether a request might be processed immediately or if a
certain interval of time should be given to the system in order to process it.
In a real-world scenario is just like a service which requires at least an a-priori time interval to take
into consideration the request (ex. a taxi company which does not takes passengers who call less
than 15 minutes before their desired pick-up time).
The measure is interesting, and the test will also be based on its analysis.
3.4.5 Vehicle Fleet
The ADARTW by Jaw presented the number of vehicles in a fleet at the beginning of the problem,
while defining the number of requests and the time span of the simulation.
Another feature it implemented was, as mentioned, the possibility to force the simulation and the
specific run to find a feasible insertion even if it did not seem possible.
The method is to add one more vehicle to the fleet any time the algorithm does not find a possible
insertion for a request. This obviously led to a widening of the fleet when advancing with time.
So for example, a fleet with 10 vehicles which could satisfy all the requests but three could
potentially end to 13 vehicles.
In a real-world situation this might be hard to justify, maybe only thinking to the surplus of
vehicles as some overtime work performed by workers who weren’t on service until that specific
time or already completed their shift before.
This would struggle to the idea of a real-time software, since it would mean that there would be a
65
certain amount of time before the new vehicles start the service; this situation appears to be
credible only by cherry picking a small amount of cases.
PTVD doesn’t implement this logic.
The vehicle fleet is fixed in its number at the beginning of the simulation, so that if an insertion is
not feasible it is simply reported as failed on the LOG file.
A file generated by a Python script is loaded into the software before the simulation begins.
What can be decided is the distribution of vehicles along the graph or the bounding box in general,
using a probability distribution. For instance, the easiest possibility would be to set the distribution
on uniform through the entire area or maybe only in a small part of it. The second possibility
might simulate the higher concentration of vehicles on a more significative zone (ex. the city
centre).
The capacity of vehicles can be set, since it is possible to divide the percentage of each capacity on
the whole fleet. So, for instance, on a hundred vehicles fleet I could set the division of 50% each
regarding vehicles with capacity limited to 4 and 6 spaces.
The Vehicles constant speed can be decided as well on the Input tab before executing the
simulation.
3.4.6 Vehicle Search Function
To increase the efficiency and avoid useless calculations, the algorithm implements a function
whom duty is to preliminary selects the vehicles in which will be later tried the insertions.
This is an upgrade from the previous versions, since they did normally select all the vehicles and
try the insertion algorithm no matter the situation of the vehicle itself.
The search function is made by sequential steps, introducing stricter criteria as much as the steps
advances. These methods are known as filters.
66
Breaking down the filters main feature, there will be:
1) Capacity Filter
As it might seem obvious, the first criteria to select if a vehicle would be feasible for an insertion is
to check its internal “crowd”.
In fact, it is a non-sense to waste computations on certain vehicles if they won’t be able to
accommodate any other passenger (or at least not the right number) in the first place.
A base assumption is, sequentially, that a request of multiple passengers cannot be split into two
or more vehicles, which it seems reasonable to any real-service scenario.
The filter checks every vehicle seat availability to cut from the choices the unfeasible ones, leaving
the remaining to the next step.
2) Bird-Distance Filter
This filter checks the current instant and the first instant in which the vehicle should reach the goal
position. If traveling a standard 150 km/h the vehicle won’t reach the goal on time, it will be then
cut from the feasibility list. The measure is taken without the graph, so it is a direct geometrical
distance.
This second filter is made to avoid taking into consideration vehicles that would later be found to
be too far from the pickup or delivery goal.
3) Whole Path Intersection
Given the request position, this filter is used to see whether the requests itself is “near” to any
vehicle path.
To clarify the method: from the given request a certain radius is taken (none less than km in a
standard situation). Now a circle around the request is created; the filter analyses if any vehicle,
during any instant of its schedule, will ever cross the border of this circle.
If so, a vehicle will be taken into consideration and later examined by the next filter, otherwise it
will be excluded from the candidate vehicles to host the request.
4) Time Slice Path Intersection
This filter tightens a little more the previous condition, giving it a temporal coordinate.
In fact, at the latest stage the path of the vehicle could have crossed the circle at a certain time.
67
Even though this is a better indicator for the proximity of the vehicle to the request, it does not
actually tells anything about “when” this happens in time.
Time Slice is made to exclude from the vehicle pool the one which would cross the path too soon
or too late from the actual Pick-Up or Delivery time. This leaves for choice only vehicle that will be
near to the request at the right time.
Figure 3-13 - Whole/Time Slice Path Inters. Filters
5) Max Vehicle Number
If all those filters would not leave the algorithm choice to just a little bunch, it is possible to limit
the maximum number of examined vehicle to a value of modeler choice.
This function actually takes into consideration the vehicle identification number, so for instance,
selecting 50 vehicles as the limit, the software would only take the first 50 vehicles in an ordinal list
from the smallest to the highest.
68
3.4.7 Cost functions
3.4.7.1 Cost functions formulations
The cost function is a fundamental piece of the software, since it is with its use that every compute
regarding the “goodness” of a solution is made.
As for many other features, PTVD cost function formulation maintains a big part of ADARTW
philosophy and meaning but changing a large part of its structure.
To notice the first difference, cost parameters C5, C6, C7 and C8 are not present in this last
implementation.
A vital function of the software is to compute the Overall and the Delta (additional) cost brought
by any possible insertion.
The software implements a specific function to compute the “differential cost” for the insertion.
The setup starts with a “New Overall Cost” set to 0 for a specific insertion.
After the recall (which is made for any selected vehicle in which an insertion may be possible), the
function primarily investigates if that vehicle has been activated already.
If not, an Activation cost has to be considered in the final overall cost. This term weights the choice
of new, non-active vehicle, preventing the software from considering these the same as already
active vehicles without paying an additional “obstacle” cost.
Based on the amount chosen by the modeler (activation cost is a parameter), this is a good way to
push the software to not use “useless” vehicles which would be an additional operational cost for
any fleet manager.
The function then investigates all the stops in the block and finds the Deviations, both from the
stop desired time and from the direct riding time. As seen before, these deviations represent the
interval of time which for which a certain stop is delayed (or anticipated if a delivery) and the
increment of the travel time given by the addition of new stops with the respect of the travel time
without those.
69
After this calculation, the “New Overall Cost” term calculated for any stop is given by:
𝑁𝑒𝑤 𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐶𝑜𝑠𝑡 += 1𝐶1 ∗ 𝐷𝑒𝑣𝐷𝑒𝑇𝑠 + 𝐶3 ∗ 𝐷𝑒𝑣𝐷𝑖𝑇𝑠
𝑁𝑒𝑤 𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐶𝑜𝑠𝑡 += 𝐶2 ∗ 𝐷𝑒𝑣𝐷𝑒𝑇𝑠2 + 𝐶4𝐷𝑒𝑣𝐷𝑖𝑇𝑠
2
Where:
𝐷𝑒𝑣𝐷𝑒𝑇𝑠 = 𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 𝑓𝑟𝑜𝑚 𝑑𝑒𝑠𝑖𝑟𝑒𝑑 𝑡𝑖𝑚𝑒 𝑓𝑜𝑟 𝑠𝑡𝑜𝑝 (𝑠) 𝑜𝑓 𝑡ℎ𝑒 𝑏𝑙𝑜𝑐𝑘
𝐷𝑒𝑣𝐷𝑖𝑇𝑠 = 𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 𝑓𝑟𝑜𝑚 𝑑𝑖𝑟𝑒𝑐𝑡 𝑟𝑖𝑑𝑖𝑛𝑔 𝑡𝑖𝑚𝑒 𝑓𝑜𝑟 𝑠𝑡𝑜𝑝 (𝑠) 𝑜𝑓 𝑡ℎ𝑒 𝑏𝑙𝑜𝑐𝑘
The function has been divided to consider the linear and quadratic terms separated.
After this passage the software calculates (for any stop as well) the amount of cost due to the
travelling time, also adding in this the time needed for the Loading and unloading phase.
𝑁𝑒𝑤 𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐶𝑜𝑠𝑡 +=1
3600∗ [𝑇𝑟𝑎𝑣𝑒𝑙𝐶𝑜𝑠𝑡𝑝𝑒𝑟𝐻𝑜𝑢𝑟 ∗ (𝑇𝑜𝑡𝑎𝑙 𝑡𝑟𝑎𝑣𝑒𝑙 𝑡𝑖𝑚𝑒 + 𝑇𝑖𝑚𝑒𝑡𝑜𝑆𝑒𝑟𝑣𝑒𝐶𝑙𝑖𝑒𝑛𝑡)]
At this point if the insertion is the first for the vehicle:
𝐷𝑒𝑙𝑡𝑎 𝐶𝑜𝑠𝑡 = 𝑁𝑒𝑤 𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐶𝑜𝑠𝑡
Otherwise, if the insertion has been made on a block which is not the first or a whole new block is
added, the slack time tied to that have to be considered with the costs.
The other term would be:
𝑁𝑒𝑤 𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐶𝑜𝑠𝑡 += 1
3600∗ 𝐼𝑑𝑙𝑒𝐶𝑜𝑠𝑡𝑝𝑒𝑟𝐻𝑜𝑢𝑟 ∗ 𝐵𝑙𝑜𝑐𝑘𝑆𝑙𝑎𝑐𝑘𝑇𝑖𝑚𝑒
If that’s the condition it is easy to understand that the blocks and the stops were already present
before this last insertion, so an “older” overall cost is present.
The software then computes the Delta cost (so the new chunks of cost that have to be paid for the
insertion) as:
𝐷𝑒𝑙𝑡𝑎 𝐶𝑜𝑠𝑡 = 𝑁𝑒𝑤 𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐶𝑜𝑠𝑡 − 𝑂𝑙𝑑𝑒𝑟 𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐶𝑜𝑠𝑡
By doing this it easy to calculate which insertion gives the smaller differential amount of cost to the
vehicle, making the choice unilateral.
1 The “+=” symbol is a coding symbol which stand for: “add this value to the previous value of that
function”. It has been kept to better portrait the function philosophy.
70
At the end of this operation “New Overall Cost” becomes the ordinary “older” cost for the block
and it will be used for the next insertion try.
Note that this procedure is made for every feasibility insertion try, so eventually only the one with
minimum resulting cost is selected to be inserted.
If any of the parameters is not respected the result cost is set to (positive) infinity, so that the
software won’t never choose it.
Obviously, if every cost returns infinity, the insertion is failed.
3.4.7.2 Optimal Shifts
A very important part of the cost section is the Optimal Shift, which is actually performed in the
last part of the feasibility insertion and might be still considered part of the insertion process.
The responsibility of the Optimal Shift is to find, inside the allowed bounds of the stops, the shift
which reduces at maximum the final cost for the insertion. To better explain this term, a stop (or a
block) may be still shifted of a certain quantity after being already shifted to obtain the constraints
respect only. The Optimal Shift module/function adds the cost minimization objective as well.
The formulation is explained as follows.
The Cost will be composed by three terms after applying the Optimal Shift:
(1) 𝐼𝑑𝑙𝑒 𝐶𝑜𝑠𝑡 = 𝑖𝑑𝑙𝑒 𝑐𝑜𝑠𝑡 𝑝𝑒𝑟 ℎ𝑜𝑢𝑟 ∗ 𝑖𝑑𝑙𝑒 𝑠ℎ𝑖𝑓𝑡 𝑠𝑖𝑔𝑛 ∗ 𝑜𝑝𝑡𝑖𝑚𝑎𝑙 𝑠ℎ𝑖𝑓𝑡
Idle cost represent the cost due to the vehicle standing not doing any operation.
Idle Shift Sign is the sign of vehicle idle time increment; in fact, the shift can be both right or left,
meaning an increase or a decrease of the slack time for the block (which by definition is the
amount of time the vehicle just stands and performs no operations).
Note that this check is performed only on the “limit” block, which are the first and last, because
the shift of the slack time in any central block just produces no increment after all (if a move a
certain quantity from a block it goes to one of the two next to it).
(2) 𝑃𝑈𝑠𝑡𝑜𝑝𝑠𝐶𝑜𝑠𝑡 = 𝐶1 ∗ 𝑛𝑢𝑚𝑏𝑒𝑟𝑂𝑓𝑃𝑖𝑐𝑘𝑈𝑝𝐶𝑙𝑖𝑒𝑛𝑡𝑠 ∗ ((𝑝𝑖𝑐𝑘𝑈𝑝𝐶𝑙𝑖𝑒𝑛𝑡𝑠𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛𝑇𝑖𝑚𝑒 +
+𝑜𝑝𝑡𝑆ℎ𝑖𝑓𝑡) + 𝐶2(𝑝𝑖𝑐𝑘𝑈𝑝𝐶𝑙𝑖𝑒𝑛𝑡𝑠𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛𝑇𝑖𝑚𝑒 + 𝑜𝑝𝑡𝑆ℎ𝑖𝑓𝑡)2)
71
In this term 𝐶1 and 𝐶2 both appear as coefficients.
Of course this term calculates the cost related to the deviation from the desired time wanted from a
customer for his Pick Up. If 𝐶2 = 0 , the equation becomes linear.
(3) 𝐷𝑠𝑡𝑜𝑝𝑠𝐶𝑜𝑠𝑡 = 𝐶1 ∗ 𝑛𝑢𝑚𝑏𝑒𝑟𝑂𝑓𝐷𝑒𝑙𝑖𝑣𝑒𝑟𝑦𝐶𝑙𝑖𝑒𝑛𝑡𝑠 ∗ ((𝐷𝑒𝑙𝑖𝑣𝑒𝑟𝑦𝐶𝑙𝑖𝑒𝑛𝑡𝑠𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛𝑇𝑖𝑚𝑒 −
− 𝑜𝑝𝑡𝑆ℎ𝑖𝑓𝑡) + 𝐶2(𝐷𝑒𝑙𝑖𝑣𝑒𝑟𝑦𝐶𝑙𝑖𝑒𝑛𝑡𝑠𝐷𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛𝑇𝑖𝑚𝑒 − 𝑜𝑝𝑡𝑆ℎ𝑖𝑓𝑡)2)
As for the Pick-Up term, this calculate the cost related to the deviation from the desired time
wanted from a customer for his Delivery.
A single function is given by the sum of these three components. The aim for this is to calculate the
best possible Optimal Shift.
To get the minimum for this function, it is just necessary to impose Optimal Shift as the variable of
the equation. The derivate with the respect to OptShift equal to zero easily find the minimum
point, which corresponds to the searched quantity.
At the end of the function the software procedure updates the PU and D instants as well as the
final shifts.
Note that the procedure shown before has been executed only to get the value for the Optimal
Shift.
72
4 Test Phase
This next phase goal is to understand how the software reacts while under defined conditions.
In particular, some input parameters will be used to push the software into different, “extreme”
situations to better understand the reactions and the output.
The following paragraphs are made to explain the condition in which the simulations are run, the
expected results, the anomalies and the possible explanations for the software behaviour.
4.1 Testing Environment
The simulations are completed on the current PTVD version, which is, as already mentioned, not a
commercial version. It is a “strong” beta, instead: it is not completely untested, but it is still not
deeply investigated in terms of expected results and possible anomalies which is, again, one of the
main aims of the work. This condition obviously requires a lot of work to be done especially on its
simulation side.
The way the inputs are loaded into the system has already been explained in the prior paragraphs.
The results have been extracted using a “Log Analyser” Python script and, when required, by
directly investigating the Log file after each run through Microsoft Excel and Notepad ++.
Any run need to happen on a given environment, which in this case is represented by a bounding
box.
The bounding box is a “blank” rectangle delimited by specific coordinates, in which vehicles and
requests are loaded. It is important to notice that the distances covered by vehicles are
geometrically computed since a graph hasn’t been used.
This choice might sound less real and not particularly good to a real-world situation but is in fact
the best way to understand the software reaction at first.
As imaginable, to generate requests in a graph may lead to misinterpretation of results, because
sometimes a PU (or D) could be in a sort of cul de sac, from which the pathfinding algorithm cannot
find a good solution.
For instance, the request might be generated in a point where the streets have a particular structure
which impedes the pathfinding algorithm to find a good solution consequently failing the
insertion. This would lead to hard results to understand, and eventually the problem would result
73
to be too hard and demanding, especially when the systems need to accommodate a lot of requests
and this type of investigation can’t be done with just an accurate visual check.
Plus, this choice allows to better adapt the study area to the different needing of the modeler.
In fact, a smaller study area has been built for the specific simulations involving a small number of
requests and vehicles, while for urban scale simulations the study area had the dimension of a
major city.
In general, the bounding box has been preferred because these analyses aimed to investigate the
software performances per se, erasing any possible source of misinterpretation or distortion from
the simulation runs.
To avoid any kind of confusion, the basic dataset is declared before any test or run explained
below; some standard inputs set it is kept the same in some given cases except where explicitly
declared.
The simulations presented on this dissertation have been run on a personal computer (Laptop)
mounting an i7 Intel Cpu and 8 Gb RAM.
4.2 Specific and operational simulations
The test sequence needs a further explanation of the difference between study phases to better
understand the aim of this next one.
The first phase of the thesis work has been of course the literature review about the algorithm to
better understand the research work done prior to this last version, to put in its right place any
element and have an overall clear mind about the Dial-A-Ride issues and modelling dilemmas.
Then, the new version of the software has been deconstructed to understand what was different
and what was not, compared to the older version. Basically, by looking at the software source code
most relevant pieces it was possible to start validating the different modules.
In other words: reading how the cost function was built made it possible to start questioning if the
theoretical construction was right and if maybe there was some space to improve it.
This step has been fundamental: in fact, even before running any test it has been possible to detect
some bugs or misinterpretations written through the code lines.
74
Also, it was possible to better recognize the mindset in which this software was created and the
following expected outcome.
After this theoretical-driven part, which was mainly focused on theory, the work shifts to the
second more “practical” part, which required several simulations runs to accomplish a satisfying
result.
Even though it might seem that the two parts are just sequential, of course it is not the case.
For the sake of comprehension, the two parts are presented on plain sequence, while the reality of
the procedure has not been so linear as imaginable.
In fact, the test sometimes highlighted one or more issues that required to go back to the previous
steps, trying to discover where the problem would possibly hide between the lines.
After making the hypothesis, the bug would have been fixed and then the tests would have been
run again.
This “back and forth” procedure is surely inevitable when talking about a new software, whom
structures still need to be deeply understood.
The tests can be divided in two major categories: specific tests and massive, urban scale tests.
Specific tests have been introduced to study the software behaviour in a more precise,
understandable way, by looking at its results while running simulations that did not comprehend
more than a dozen requests and vehicles.
By using this strategy, one could possibly build a specific situation to understand all the
mechanism the software uses to work.
The procedure has been to tailor a test “on paper”, so calculating by hand the expected outcome,
and then testing if the software would deliver the same result.
It can be seen as a proper “debug” phase, since it is a big part of any new software development to
study a certain piece of its working feature in any detail before focusing on larger scale issues and
malfunctions.
Massive operational tests have on the other hand served as an indicator of the test behaviour for
operative conditions. This means a high number of vehicles and sometimes several requests per
second.
75
The aim should be clear, since the software eventual primary function would be a “field” use for
transport situations in which a high response speed is required, coupled with great precision.
The next paragraphs will present the tests (or just the highlights) and the purpose for each chunk.
4.3 Specific Tests
As already mentioned, these tests are made to surgically analyse the software algorithm and
procedures in any details, understanding if any sort of bug or unexpected result must be fixed.
The scenarios presented in the following paragraphs have been prepared a-priori, manually doing
all the calculations and the consequent hypotheses on the software behaviour.
This served as a fundamental verification proof.
In fact, when a situation did not reflect the expected result, which were calculated by looking
directly into the PTVD source code and couldn’t be misled, has to be considered a signal that lead
to a new Debug phase.
Even though the scenarios are not very complex, these have been accurately tailored to investigate
certain parts of the software algorithm that were too hard to investigate when a massive analysis
was started.
Of course the ease of any scenario analysis was since, as already mentioned, any calculation had to
be made “by hands”, meaning that a more complex situation could lead to a mistake on any
passage.
To translate the scenarios from paper to the software, a different kind of script has been used.
In fact, instead of just “shooting” random requests following certain characteristics, a Deterministic
Shooter has been written for this specific purpose.
The task of this shooter is to decide any small detail for every request, from the Call Time and
Desired time, to the number of passengers and the amount of time needed for loading and
unloading.
76
4.3.1 Test 1
The test aim is to describe a situation in which only one vehicle has the task of 3 different requests,
any of these with a different Call Time and Desired Time.
The focus would be primarily directed towards the insertions tries and the software way of
deciding which feasibility vehicle would best fit the request (i.e. will eventually have the minimum
Overall cost).
Only one vehicle is loaded into the system to solve the requests.
Since the requests have been found on the bounding box with coordinates following WGS 84
system, any of these has a certain longitude and latitude, while the comment will only focus on
their relative distances.
The tables below describe the characteristics for the vehicles, the parameters and the requests.
Number of total vehicles 1
Constant Speed 30 km/h
Capacity 2 Passengers
Table 3 - Vehicle characteristics
Activation cost 106 €
Idle cost per hour 1 €/hour
Travel Cost per hour 10 €/hour
C1 1 €/hour
C2 0
C3 1 €/hour
C4 0
Table 4 – Parameters
Request n° Type CT DT
1 Pickup 19:00:00 19:08:00
2 Delivery 19:10:30 19:37:00
3 Pickup 19:11:05 19:12:00
Table 5 – Requests
77
Figure 4-1 – Initial Scenario
The first request is a pickup.
By construction, the distance between PU and D is 8 km, so with a speed of 30 km/h it can be
travelled in exactly 8 minutes.
The direct consequence is the creation of a new block without any additional slack time since the
vehicle has to depart as soon as possible to satisfy the request.
The expected result is to have the Actual pickup Time equal to Desired time, also paying the
Activation cost, since it is the first operation performed by the vehicle.
The only possible insertion is made by trying an insertion with feasibility I (the block is of course
still empty at the beginning).
Request 1
Request 2
1 K
m Request 3
4 K
m
1 Km
Multiple Requests in the same point
78
The second request is a delivery and arrives at 19:10:30, so while the vehicle is still traveling to the
first request delivery.
DT is very wide this time at 19:37:00, meaning that more than one feasibility is tried for the
insertion.
In particular:
➢ One possibility would be to stop travelling to reach the delivery for the first request, take a
detour to get to the second request Pickup point, get to the second request delivery point
and then finish the first request by eventually delivering the customer.
This possibility is a Feasibility II.
Although it could be possible to try the insertion, it would lead to an excessive time loss
because of the maximum allowed riding time, which is only 2 times the Direct riding time.
The customer for the first request would be forced to wait on board a time that would then
result too long.
This possibility is then excluded.
79
➢ It might be possible to insert the request by using feasibility 3.
That would mean, just like before, to skip the delivery for the first request, go for the
second request pickup, then finish the delivery for the first request and eventually
complete the second request.
The insertion results to be impossible because of the incompatibility of EDT and actual
delivery Time.
➢ Another option the software would try is the insertion at the beginning of the block (which
is still Feasibility II); it is immediate to notice that the insertion is impossible due to the fact
that the insertion would have to modify events and schedules already belonging to the
past.
It might be theoretically possible for this type of insertion to try its operation (as already
properly explained on the chapter explaining in details the Feasibility II functioning).
Although the theory allows it, so far, a code constraint is to avoid insertions at the
beginning of blocks, both current or directly next to the one the software is trying the
insertion on.
So this type of insertion is in fact immediately discarded.
80
➢ The other possible option would be to try feasibility I, so an insertion after the last stop of
the block.
Because of the large slack time given to the second request, the insertion at the end of the
first block would be useless, since it would lead to a greater anticipation of the delivery
time, leading to a higher insertion cost.
It is important to remember that, for a delivery, the cheapest (so actually the best) option is
to make the DT coincide with the Latest delivery time. It is absolutely forbidden to deliver
after the LDT.
The consequence would be the creation of a second block with its slack time (13 minutes)
that makes the vehicles stop right after the end of the first request, wait until it’s time to
depart again and then complete the operations.
The third request, which is a Pickup, arrives while the vehicle has already started the unloading
phase for the first request. The request has been designed so that the pickup is exactly 4,5 minutes
to travel away from the second request pickup.
As clear by the scenario picture above, the request is not on the same “line” as the other two, but
81
its longitude is slightly on the right side.
The DT for this request is very strict (19:12:00, 30 seconds after the call time), meaning that the
vehicle have to depart immediately to satisfy the request with the lowest possible amount of time.
To insert this request a detour is needed, but of course it will have to respect any boundary
regarding shifts, Latest an Earliest delivery times.
The software tried 6 different insertions but only two of these respected these constraints.
The two possible insertions are explained below
➢ The Feasibility II tries to insert the Pickup and the Delivery consecutively in the middle of
the block.
As said for the precedent request, even thou it might be possible to insert at the beginning
of the block, at the moment the software discard any type of insertions which operates this
way.
This thing leads to the only possibility for F II to insert after the first stop of the second
block.
The sequence would be: PU2, PU3, D3, D2.
To do so, the vehicle have to reduce its slack time, which is already planned.
The two stops “eat” the slack time by shifting the PU for the amount needed to complete
their operations (detour + load + unload). Note that while it would be theoretically possible
to shift the second request delivery, it is not a possibility, because it would lead to an actual
delivery time higher than the latest delivery time (strictly forbidden condition).
Plus, as already explained, the first operation the software performs is to shift the “left”
side of the block (the prior stops) before even trying to shift the “right” side (the following
stops with the respect of the new insertions).
82
➢ The Feasibility III tries to insert the Pickup between the second request Pickup/Delivery
couple, then it consider the Delivery at the end of the second block.
Using the same logic as seen before, the stops have to be shifted on the left side to place the
new stops.
Both the solutions are possible when it comes down to insertion.
By the way, costs are then taken into consideration, resulting in a slightly better result with
Feasibility II solution.
It is important to notice that in these situations the parameters regulate the final result, since they
can give more or less weight to a certain disutility.
For instance, C1>C3 would lead to an increased importance for the deviation from desired time at
the expenses of the deviation from the riding time.
The test has been conducted several times to investigate whether the software would follow the
expected procedure or not.
The simplicity of the situation allowed to reconstruct any passage with ease, calculating the costs
perfectly, making sure that any possible bug would be found and fixed.
This test has been fundamental to validate the software insertion procedure and operate the right
corrections to code structure and software theory.
83
4.3.2 Test 2
This second test aims to verify the correct functioning of the Activation cost.
The Activation cost must be considered a measure to prevent too many vehicles from doing
operations that could be done by a lower number of those.
In fact, while use a larger number of vehicles than needed might result in a lower cost for users, on
the operational side it is indeed convenient to slice the costs as much as possible.
It is then vital for this measure to work properly.
Number of total vehicles 3
Constant Speed 30 km/h
Capacity 2 Passengers
Table 6 - Vehicles characteristics
Activation cost 106 €
Idle cost per hour 1 €/hour
Travel Cost per hour 10 €/hour
C1 1 €/hour
C2 0
C3 1 €/hour
C4 0
Table 7 - Parameters
84
Figure 4-2 - Initial Scenario
Request n° Type CT DT
1 Pickup 19:00:00 19:02:00
2 Delivery 19:07:00 19:16:00
3 Pickup 19:15:30 19:16:00
Table 8 - Requests characteristics
In this test we do not worry about the feasibility used for the insertion, since it will always be the
Feasibility I because of the distances and the Call Time/Desired Time for any requests.
As already explained, the focus will be on whether the Activation Cost works fine for any request
and favours the vehicle that already planned and performed some operations instead of
considering a new vehicle anytime.
Request 1
Request 2
V2
Request 3
2 Km
2 K
m
1 K
m
V3
V1
85
The first request simply can only be taken by vehicle V1, because of the strict desired time for the
Pickup, which allows V1 to be the vehicle to get the request without any deviation from DT.
Of course, at the beginning any vehicle is subject to the “payment” of the Activation cost, so it is
just a matter of which one fits best in this case.
The delivery of the requests (and the actual position for V1) lands just 2 km away from V2.
The second request is a Delivery, whom origin is set to be exactly in the midpoint between V1 and
V2.
The Call Time is such that the first vehicle already performed the first request and is now in idle
state, waiting for a new one.
This means that both vehicles should have an overall similar travel cost (also because the Idle Cost
per hour is very low on our parameters).
The situation “balancer” should be the Activation cost.
Only V1 has been activated so far, meaning that the final insertion cost for V2 should increase of
106, resulting in a clear choice towards V1 for the insertion.
The third request basically stretches the same logic while adding other stricter conditions.
In fact, the CT for this last request is such that coincides with the unloading phase of the second
request. Plus, DT is imposed for 19:16:00, which is basically the CT and an additional 30 seconds.
V2
2 Km
1 Km
1 K
m
V1
86
The direct consequence is that V1 should gain a good amount of deviation from desired time,
while V3 would take the requests with a smaller amount of delays.
As for the prior situation, V3 hasn’t been activated yet, meaning that the overall cost for the
request would still make the software choose V1 because of the extremely high Activation cost we
chose.
Of course, when the Activation cost is not this high the software behaviour is to consider any
inactive or active vehicle the same, so that its main priority becomes to satisfy all the requests
while keeping the deviation from Desired Time at the lowest possible level.
The activation cost is a vital part of the software functioning, which is the reason why it has been
widely investigated in this test.
It is always to be fixed in mind that costs reflects the customers satisfaction for the service.
The main function of PTVD is of course to get the maximum amount of successful inserted
requests over the total amount received.
Cost function parameters are made to bend the software behaviour to the modeler’s choice.
When putting these high values for activation cost the functions are advantaging service operator
needs over users.
In fact the cost is such that PTVD prefers to give a discomfort to a user (in the form of waiting time,
V2
1 Km
2 Km
V3
87
time spent on board, delays and anticipation) to insert a certain request in an already active
vehicle.
While this might be seen as a total discomfort and an uneven situation, on a real-case scenario the
factor allows to solve a high number of request with less vehicles.
In real-world the obvious consequence for a service operator would be to have fleets with a lower
number of vehicle, probably needing less maintenance and personnel cost.
This would then reflect on customers, which would be indirectly advantaged by things such as
lower fares or more convenient prices.
On the other hand, to keep a lower (or non-existent) Activation cost would certainly advantage
user comfort.
Looking at the formulation the terms with the highest “weight” would be the C’s and the
deviations (which are also quadratic).
As for the other case, the immediate result would be a gain in terms of respected schedules and
comfort, but a higher number of vehicles involved and “forced” to activate in order to avoid a
scarce service quality that would leave customers with a bad opinion or unsatisfied.
4.3.3 Test 3
The aim for this third test is to have a little more focus regarding the Vehicle search functions and
the slack time related costs.
Vehicle search function is a great improvement over the latest implementations, because it allows
the software to “slice” through the vehicles around a certain requests to only select the ones that
could actually perform the request.
Obviously, this allows to avoid calculations for any vehicles loaded into the simulation, highly
downsizing the cost calculations.
The search function is based on two main parameters, which are the search radius and the
maximum number of selected vehicles.
88
Number of total vehicles 2
Constant Speed 30 km/h
Capacity 2 Passengers
Table 9 - Vehicles characteristics
Activation cost 106 €
Idle cost per hour 1 €/hour
Travel Cost per hour 10 €/hour
C1 1 €/hour
C2 0
C3 1 €/hour
C4 0
Vehicle Search Radius 3,5 Km
Table 10 – Parameters
Figure 4-3 - Initial Scenario
Request 1
Request 2
V2
Request 3
2 Km
1 K
m
V1
1 K
m
Vehicle search radius
Request Position
89
Request n° Type CT DT
1 Pickup 19:00:00 19:06:00
2 Delivery 19:01:00 19:02:00
3 Pickup 19:15:00 19:16:00
Table 11 - Requests characteristics
As seen on the table, the search radius has been kept to 3.5 km.
The reason for this very precise measure has to be seen in the requests position and call time, as it
will be clearer while explaining the requests partitions.
The first request CT is set to 19:00:00 with a DT for 19:06:00.
The radius is such that when getting to the whole path filter, the software would only recognize V2
because of its position near the request.
Since it is a Pickup, the requests won’t be executed at the earliest possible time because the origin
can be just reached with a 2 minutes ride.
A slack time is generated at the beginning of the first block, while the vehicle won’t start its ride
immediately.
Figure 4-4 - Search radius functioning scheme
3,5 km Search Radius
The already scheduled
path is intersected by the
radius so the vehicle is
taken into consideration.
90
The second request arrives at 19:01:00, with a very strict DT at 19:02:00 and a very near position to
V1.
In this case, the radius from the request would only intercepts V1 with its area, but a fundamental
difference is that it should also intercepts V2 path to satisfy the first request, which have already
been traced and fixed. As said, the test was made to check whether the vehicle search function
would work while considering another vehicles path.
Even thou the position might be better to force V1 to execute the request, the fact that Activation
cost is still high, and the first request was very large with its DT would lead to V2 to take the
request.
To avoid this, the second request has been generated with a smaller Time Window than the
average (2 minutes), which only allows V1 to execute the request.
This would also exclude V2 to be considered as a possible vehicle for the request, because of the
Time slice path intersection filter, which checks whether the path is intersected in the right interval
of time.
The situation is now that both vehicle performed their requests and are distant two kilometres
from each other.
A new request is generated right in the midpoint of the segment which unites the two.
The CT for this request is such that both of the vehicles have abundantly completed their previous
tasks and are now waiting on Idle condition.
Figure 4-5 - Request slack time
91
The software elaborates which one of the vehicles has a lower overall cost.
The Activation has been taken out by the decision process because both of the vehicles performed
a request and the deviation time would be the same (because of their symmetric position with the
respect of the new request).
So the decision would be take considering the vehicles that has the least amount of slack time, in
this case orienting the decision towards the vehicle to stop for first, because of the cost functions
structure which takes into consideration the amount of slack time for any block.
The radius for the vehicle search function has revealed itself to be an efficient instrument to have a
first “cutting” from the whole vehicle fleet.
It has been tested with several increasing measures to comprehend if the actual results were
attached to the expected results.
As expected, when the radius was set under 3 km of length, the software couldn’t really consider
both vehicles after applying the whole path intersection filter.
When it overcame the 3 km barrier, the vehicle search function could intersect the scheduled path,
while, as it was forecasted, the time slice path intersection filter wiped the useless vehicle from the
choice.
After this validation the radius has been set to 3,5 kilometres for the test above.
The vehicle search function reveals itself to be a powerful instrument, but it is indeed something
that must be properly calibrated thinking about the result the modeler wants to obtain.
In fact, a lower radius might only select vehicles nearer to a certain request ignoring farter ones. Of
course this logic it is not wrong per se, because the probabilities to find vehicles to satisfy a certain
request are surely higher if located not far from it.
This might actually be an issue only for big study areas and specific cases in which Call time is
much lower than desired time, so that a vehicle might arrive on time to take a request but it is
excluded from the candidates on the vehicle search phase.
However, the software has been thought and wrote for more urban scale, real-time cases, in which
these kind of issues surely have a smaller impact.
The second part returned to check the efficiency of the cost functions, with a focus on the part
regarding the cost applied for slack time (i.e the Idle state of vehicles).
92
4.4 Aggregated test and operational conditions
This second part is dedicated to exploring the operational dimension of the software.
Operational means that the magnitude of the problem is as big as an average (or way more) real-
world situation.
In this case the measures of the Bounding box have been tailored around the city of Turin.
Turin has an official surface of 130 square kilometres, while our bounding box is a square whom
area is 225 square kilometres.
Figure 4-6 – Urban Test Study area/bounding box
The vehicles are assumed to move at a constant speed of 30 km/h, and because of the definition of
bounding box, the distances are computed and covered geometrically without using a graph
(Euclidean).
All the requests are for a single passenger only and the time for loading and unloading have been
considered as 1 minute.
The pickup have been considered as real-time, meaning that the difference between the request
Call time and the Desired time is randomly a minute or less.
The deliveries have a Desired time which takes into consideration the time to get from origin to
destination, the time of loading and unloading plus a random quantity between 5 to 10 minutes,
15 K
m
15 Km
93
which is also strict but enough to allow the actual performing of the delivery.
It is important to remember that a delivery cannot be done after the DT, so in case of a unreal
condition (like Call-time plus one minute), the delivery would be immediately failed.
While the requests are uniformly distributed on the whole bounding box, the maximum distance
between Pickup and Delivery has been set to 6 km, so the application are actually made for a short
trip type of service.
The time windows for any request is always 15 minutes, both for pickup and for deliveries.
The multiplicative factor for the calculation of the maximum riding time is 2.
The vehicles have been always distributed over the entire bounding box following a uniform
distribution, as well as the requests. The total number of vehicles distributed for any simulation
run is equal to 3500.
Instead of considering a mixed fleet, the choice was made to take a homogeneous one anytime, to
better analyse and comprehend the software behaviours and, if so, the limits.
Regarding the cost functions it is important to know that the activation cost has been set to 106,
while the quadratic components of the deviations are not considered and have been set to zero.
The Travel cost per hour is 10 and the Idle cost per hour is 1.
The simulations are real-time, so a two-hour simulation takes that amount of time, to better
reproduce the real-world scenario.
Any value in the graphs has been obtained with a minimum of two 120 mins run averaging any
result.
5 different scenarios have been built to explore different software cases and have a wider
perception of the results.
Scenario Vehicles capacity Vehicle search radius (meters) C1/C3
1 1 2000 1
2 2 2000 1
3 4 2000 1
4 4 2000 2
5 4 1000 1
Table 12 - Scenarios summary
94
Any of these will be analysed through some KPI’s and later commented.
The KPI’s used for this purpose are the number of used vehicles to accomplish a certain request
rate, the average deviation from the Time window calculated from any satisfied request and the
average deviation from direct riding time calculated as the precedent.
Another fundamental indicator would be the ratio between the number of inserted requests and
the number of total request for a certain run.
4.4.1 First Scenario
The entire fleet has a homogenous capacity equal to 1, which is of course the minimum to allow
any kind of service for the software.
The request rate per hour started from 1000 and has been raised up to 30000, which has been
recognized as the limit for a good quality service.
The results are exposed in the table below.
Rate 1000 5000 9500 14000 21000 24000 27000 29000 30000
N° Vehicles 328 1144 1984 2862 3500 3500 3500 3500 3500
Avg.
Deviation TW 305.9 287.5 276.3 270.3 284 317 373.9 412.7 412.8
Avg.
Deviation RD 0 0 0 0 0 0 0 0 0
Inserted (%) 97 97 97 97 95 90 84 80 79
Table 13 – First Scenario tests results
It is important to notice that the zero values for the average deviation from Direct riding time are
perfectly normal: since a vehicle can only accomplish one request at a time, the block can be only
formed by two stops, meaning that any other insertion that might shift the two already planned it
is impossible by definition (new requests can only be inserted through feasibility I).
The graphical representation of the results are as follows.
95
Figure 4-7 - Test results
The used vehicles curve reaches its limit at a range which floats around 21000 requests per hour.
While the percentage of satisfied requests it’s steady until 15000 req/hour, it starts decreasing for
higher rates, as it is expectable.
In particular, from 20000 to 30000 the decrease it’s very steep, meaning that the fleet has overcome
its capacity and cannot handle higher ratings without heavy degrading the service quality.
Figure 4-8 - Inserted/processed requests
0
50
100
150
200
250
300
350
400
450
0
500
1000
1500
2000
2500
3000
3500
4000
1000 5000 9500 14000 21000 24000 27000 29000 30000
Dev
iati
on
s (s
)
Use
d V
ehic
les
Rate per hour
Capacity =1, Radius = 2000, C1/C2 = 1
Used Vehicles
Avg Dev TW
0,7
0,75
0,8
0,85
0,9
0,95
1
1000 5000 9500 14000 21000 24000 27000 29000 30000
Satisfied Requests
96
The decreasing in service quality is witnessed by the Average deviation from Time windows.
The first thing to notice is that it starts at a higher value, then it decreases when rates are
comprised between 5 to 15 thousand requests per hour, then it starts growing overcoming the
initial value.
The interpretation of the results suggests that, because of the high activation cost, the software
prefer to insert the requests inside already Active vehicles.
As already mentioned, this vehicles cannot really accomplish two requests in the same block, so
the vehicle basically does not complete any detour.
So any “newer” request needs to hold until the vehicle with the lower cost has finished its
operation and it is able to take on the next.
This explains a high starting value for this parameter which immediately start to decrease after a
higher amount of requests need the activation of several more vehicles.
Of course, raising the amount of requests leads to a situation in which the number of vehicles that
can be activated is reached. After this peak, the steep of the deviation trend gets a decisive gain,
meaning that to satisfy all the requests, vehicles have a queue of requests that can only be satisfied
one at a time, leading the customer on the bottom of the line to have an increment in their waiting
time.
After a certain rate, the deviation seems to return steady, while the inserted requests have wider,
faster worsening, suggesting that the limit for this configuration has been reached.
4.4.2 Second Scenario
The entire fleet has a homogenous capacity equal to 2, the difference from prior scenario regards
the capacity of vehicles.
Because of this additional capacity for any vehicle, the rate per hour has been investigate up to
40000 requests per hour.
97
Rate 1000 5000 10400 15000 20000 24260 30000 35000 40000
N° Vehicles 313 1061 1898 2690 3197 3484 3500 3500 3500
Avg. Deviation
TW 303.5 299 306.6 316.7 326.6 341.6 372.4 425.3 464
Avg. Deviation
RD 50.3 49.8 50 49.9 49.7 50.3 50.6 51.8 54.5
Inserted (%) 97 97 97 97 97 95 89.4 84.1 76.6
Table 14 – Second Scenario Test results
Of course, for any capacity higher than 1 it is important to consider the average deviation from
riding time as a parameter for the service quality on the customer side.
Figure 4-9 - Test results
0
50
100
150
200
250
300
350
400
450
500
0
500
1000
1500
2000
2500
3000
3500
4000
1000 5000 10400 15000 20000 24260 30000 35000 40000
Dev
iati
on
s (s
)
Act
ivat
ed V
ehic
les
Rate (requests/hour)
Capacity 2, Radius 2 km, C1/C3 = 1
Used Vehicles
Dev TW
Dev DRT
98
Figure 4-10 - Inserted/processed requests
The number of used vehicles growth is still high, but the steep is sensibly lower than the previous
case with capacity = 1, so that the curve reaches its peak a little bit later.
The percentage of satisfied requests is steadily over 95% for a rate up to 25000 requests per hour,
already overcoming the previous scenario as forecasted.
Although, after this rate the performances really start to decrease heavily, since it is not possible to
activate the right amount of vehicles to complete all the requests.
For a rate of 40000 requests per hour only 3 quarters of the requests have been satisfied, with a
peak of average deviation from Time window.
Speaking of which: the TW deviation steadily grow throughout the graph, having a decisive
acceleration for rates higher than 30000 requests per hour.
While at the beginning the number of seconds is basically coincident with the previous scenario, it
is sensibly lower for any higher rate.
The deviation from direct riding time surely has a little addition for very high rates, but it basically
oscillates around the same values through the whole scenario, suggesting a low variation on the
amount of detour the vehicles need to perform for any request.
This phenomenon is explained by the fact that capacity is only able to accommodate 2 requests at
the same time, meaning that it is very hard to have a lot of detour for the same requests block.
0,7
0,75
0,8
0,85
0,9
0,95
1
1000 5000 10400 15000 20000 24260 30000 35000 40000
Satisfied requests
99
4.4.3 Third Scenario
Just like the difference between the first and the second scenario, in this case the capacity of any
vehicle in the fleet has been raised to 4 units.
The simulation results are summarized in the table below.
Rate 1000 5000 10000 15000 20000 23800 30000 35000 40000
N° Vehicles 324 999 1778 2531 3094 3364 3497 3500 3500
Avg. Deviation
TW 271.2 288.7 294.8 304.86 310.45 320.08 341.05 379.8 413.31
Avg. Deviation
RD 60.74 74.4 75.75 78.03 78.66 77.45 78.29 80.9 84.73
Inserted (%) 97 97 97 97 97 95 91 86 80
Table 15 - Third scenario test results
It is expected from the used vehicle curve to have a lower pendency, as a sign that the software can
find an already active vehicle with enough space to accommodate another request.
Figure 4-11 - Test results
0
50
100
150
200
250
300
350
400
450
0
500
1000
1500
2000
2500
3000
3500
4000
1000 5000 10000 15000 20000 23800 30000 35000 40000
Dev
iati
on
s (s
)
Act
ivat
ed V
ehic
les
Rate (Requests/hour)
Capacity 4, Radius 2 km, C1/C2 = 1
Used Vehicles
Dev TW
Dev DRT
100
Figure 4-12 - Inserted/processed requests
The graph shows the tendency regarding the number of active vehicles, which is of course quite
smoother up to 30000 requests, where the curve reaches its peak and it is slightly later than the
previous scenarios.
Figure 4-13 - Used Vehicles comparison, Scenarios 1, 2 and 3
0,7
0,75
0,8
0,85
0,9
0,95
1
1000 5000 10000 15000 20000 23800 30000 35000 40000
Inserted/processed requests
0
500
1000
1500
2000
2500
3000
3500
4000
1000 5000 9500 14000 21000 24000 27000 29000 30000
Use
d v
ehic
les
Rate per hour
Used vehicles Comparison
Capacity= 1
Capacity= 2
Capacity= 4
101
The TW deviations are significantly lower for any rate with the respect of the second scenario,
while the behaviour in terms of steep growth for higher rates it’s pretty much the same, showing a
constant increase for the whole scenario with a decisive increment on the final part.
Figure 4-14 - Average Time windows deviations comparison, Scenarios 1,2 and 3
As expectable, the satisfied requests percentage is considerably higher than the previous scenarios.
In fact, for 40000 requests we have the lower bottom at 80 %, while for the previous cases was
already way under this quantity.
It is interesting to notice a different behaviour for the DRT deviation curve.
In this occasion in fact there is a constant increase with the rate.
Even thou it is limited in terms of seconds since the difference between the value at 1000 and at
40000 requests per hour is just 24 seconds, it is indeed an outcome to discuss.
In fact, while in the previous case this quantity remained constant because of the limited capacity
of the vehicle, the augmented capacity allows any vehicle to easily perform more insertions in the
same block, since it is now possible to take charge of those.
The rate growing underline this behaviour even more.
It is easy to imagine that when the requests are this high and the fleet is limited, the software need
to search the possible insertion in any already active vehicle, forcing it to take a detour to
250
270
290
310
330
350
370
390
410
430
0 5000 10000 15000 20000 25000 30000 35000
Dev
iati
on
(s)
Rate per hour
Avg. TW deviations Comparison
Capacity1
Capacity2
Capacity4
102
accommodate as much requests as possible.
On lower rates the needing of this it’s surely less impacting.
4.4.4 Fourth scenario
This scenario aims to investigate different parameters.
So far, the cost functions have assigned the same weight to both the Time Windows and Direct
riding time deviations, meaning that the software read those as equally inconvenient for a general
customer.
As already specified in the introduction, the quadratic terms are not considered in the different
cases.
On the other hand, in this investigation the ratio between the two linear components has been
changed so that the ratio results: C1/C2 = 2.
This condition should give a stronger importance to the time windows deviations, meaning that an
average customer would fine more disappointing a late arrival of the vehicle to pick him up (or to
deliver him) rather than a longer trip to the destination.
The table shows the results for the scenario.
Rate 1000 5000 10000 15000 20000 24090 30000 35000 40000
N° Vehicles 307 951 1753 2416 3042 3354 3492 3500 3500
Avg.
Deviation TW 248.4 266 269 271.8 283 291 315.6 353.6 387.5
Avg.
Deviation RD 59.7 74 77.8 79.1 80 80.5 80.7 82.8 86.17
Inserted (%) 97 97 97 97 97 96 91 87 81
Table 16 - Fourth scenario results
103
Figure 4-15 - Test results
Figure 4-16 - Inserted/processed requests
0
50
100
150
200
250
300
350
400
450
0
500
1000
1500
2000
2500
3000
3500
4000
1000 5000 10000 15000 20000 24090 30000 35000 40000
Dev
iati
on
(s)
Use
d V
ehic
les
Rate per hour
Capacity = 4, Radius = 2 Km, C1/C2 = 2
UsedVehiclesTW Dev
Avg Dev RD
0,7
0,75
0,8
0,85
0,9
0,95
1
1000 5000 10000 15000 20000 24090 30000 35000 40000
Satisfied Vehicles
104
While the number of used vehicles is pretty much the same as well as the percentage of satisfied
requests (as expected since the capacity of the fleet is the same), the deviation had a significant
change.
The most evident and obvious reaction to this change of parameters is that the average deviation
for the time windows is surely lower because of the higher weight of these time losses in terms of
costs.
Figure 4-17 - Third and fourth scenario TW Deviation comparison
While maintaining the same behaviour of a stronger addition on the last part of the graph where
the higher rates lie, this steeper segment is surely smoother and less edgy than the previous
scenarios.
Regarding the deviation from the riding time, it is mildly lower for the first part of the graph, to
get higher than the previous scenario on the latter part of it.
This probably suggests that while this re-arranged ratio may have some sort of effects on the RD
deviations too, probably the most important parameters is still the capacity of the fleet.
200
250
300
350
400
450
1000 5000 10000 15000 20000 24090 30000 35000 40000
Deviation from TW
C1/C2 = 2
C1/C2 = 1
105
4.4.5 Fifth Scenario
As for the previous scenario, this following case wants to cover another important parameter
needed for the software.
In this setting, while the cost parameters ratio has returned to 1 and the fleet capacity has been
kept to 4, the radius for the vehicle search has been diminished, arriving to a smaller value of 1000
meters.
Because of its functioning already explained on the third specific simulations, it is interesting to
investigate whether this may be an important characteristic to define the software outcomes.
The following table sums up the results:
Rate 1000 5000 10000 15000 20000 24090 30000 35000 40000
N° Vehicles 490 1556 2486 3269 3487 3500 3500 3500 3500
Avg. Deviation
TW 243.9 267.7 274.2 281.7 295.2 308.1 339.3 375.8 432
Avg. Deviation
RD 49.4 65.7 67.8 70.4 71.6 73.1 76.9 80.7 86.6
Inserted (%) 97 97 97 97 95 92 87.6 81 74.2
Table 17 - Fifth scenario test results
Clearly, the overall results had a decisive overall worsening.
The graphs may show this behaviour clearer.
106
Figure 4-18 – Test results
Figure 4-19 – Inserted/processed requests
The used vehicle curve reaches its peak “sooner” than the same scenario with a wider radius.
This outcome has an easy interpretation: since the radius is responsible of the vehicle selection for
any request, to diminish its length means to limit the number of vehicles that are taken into
0
50
100
150
200
250
300
350
400
450
500
0
500
1000
1500
2000
2500
3000
3500
4000
1000 5000 10000 15000 20000 24090 30000 35000 40000
Dev
iati
on
s (s
)
Use
d V
ehic
les
Rate (Requests/hour)
Capacity = 4, Radius = 1 km, C1/C2 = 1
Used Vehicles
Dev TW
Dev DRT
0,7
0,75
0,8
0,85
0,9
0,95
1
1000 5000 10000 15000 20000 24090 30000 35000 40000
Satisfied Requests
107
consideration.
Because of this consequential effect, the probability of finding an already active vehicle which can
satisfy a requests decreases.
Figure 4-20 - Third and Fifth scenario Used vehicles comparison
This translates into the needing of a higher number of vehicles to satisfy the same rate of requests.
Of course, both the situations end with the total number of the fleet activated because of the
massive number of requests.
This outcome might suggest that in order to have the best result in terms of used vehicles the only
thing to do is just augment the radius. While this solution is true and feasible for situations in
which the requests rate are lower than 20000 requests per hour, on the higher side this leads to an
amount of computing time that in the end causes a delay and a queue on the requests resolution
side.
In fact, the radius equal to 2000 meters is the right amount to allow the software to keep an
insertion time (time needed for computation) low enough to create no queue; it is important to
keep in mind that the software works on the insertions on a consecutive-single basis on a FIFO
philosophy.
The radius also affects the percentage of satisfied requests.
0
500
1000
1500
2000
2500
3000
3500
4000
1000 5000 10000 15000 20000 24090 30000 35000 40000
Use
d V
ehic
les
Requests per hour
Used Vehicles
Radius = 1
Radius = 2
108
Figure 4-21 - Third and Fifth scenario Inserted/processed comparison
As for the number of used vehicles, a smaller radius sensibly worsens the number of requests
satisfied by the same number of vehicles.
Regarding the deviation from DRT, while both scenarios have an ending value which is pretty
much the same, for lower rates a lower radius have less deviations.
Figure 4-22 - Third and Fifth scenario deviations from DR comparison
This behaviour is explained by the fact that the software can only detect feasible vehicles near to a
certain request, resulting in detours that are lower because of the limited number of meters that
have to be performed to satisfy a request.
0,7
0,75
0,8
0,85
0,9
0,95
1
1000 5000 10000 15000 20000 24090 30000 35000 40000
Insertion percentages
Radius =1
Radius = 2
40
45
50
55
60
65
70
75
80
85
90
1000 5000 10000 15000 20000 24090 30000 35000 40000
Deviations from DR
Radius = 1
Radius = 2
109
5 Conclusions and discussion
This work presented a software to solve real time Dial-A-Ride problems, focusing on its internal
theoretical construction, its functionalities, operative strengths and limits.
Its usage demonstrated the possibility to optimize solving problem that are attested on a massive
scale, even through situations in which the software had to manage a very large number of
requests in critical conditions.
The aggregated results aimed to show the reaction of this software when tested under many
different situations which are mostly based on possible real-world simulations, at least in terms of
magnitude and computational speed.
While the software development is far from over and ready to implement more functionalities, it
proved to be a reliable efficient tool capable of handling large scale real-time problems.
The possibility of using a graph, a city model in general and to upload the different traffic states
during the simulation is already possible, while still needs to be tested for validation.
These functions will be capable of shaping and modelling precise and truthful scenarios, which
could lead to a deeper level of analysis.
The real-time functioning of the software might evolve so that it could calculate the travel time
based on the actual traffic state, plus all the other stops that are already scheduled may be
“uploaded” in terms of actual travel time to get to destination.
This last occasion would lead to greater amount of theoretical computations, since to miss a time
window for an already planned stop, which is later proved infeasible because of the actual traffic
state, would require different assumptions.
As an addition, the type of code required for this new function would be surely more complex and
demanding in terms of computing power.
Another step of the development may consider the possibility to further improve the vehicle
selection part to make it more efficient and solid.
Since the market is now very demanding in terms of usage speed and precision, to meet the
competitiveness requirements is a hard challenge.
While it might still require further development, the absolutely encouraging results achieved by
110
PTVD in this early stage are a good firm point which surely confirm the possibility to implement
its usage for commercial and research purposes in the immediate future.
6 Appendix
The appendix contains all the scheme representing the different feasibilities logic paths.
Thanks to Claudio Catta for his work on building the schemes.
Legend:
p, q, r, s: these indexes are used to mark the sequence of stops the vehicle is trying the insertion
through. Given the Pickup stop (+ i) and the Delivery stop (- i) for the customer, the 4 feasibility
cases can be seen as:
F_I 1……p (=d) + i - i
F_II 1……p + i - i q……d
F_III 1……p + i q……d - i
F_IV 1……p + i q……r -i s……d
Ti (T-i): The pickup (delivery) time for the new customer.
STj: scheduled time for the stop before the new insertion
wi: Slack time changing due to the new insertion
SHIFT: the amount of time the block or the stop have to be trailed
∆Pi (∆Di): detour time needed to Pick up (deliver) the new customer
PS (DS): the amount of time for which the stops which precedes (succeeds) the insertion of the new
customer i have to be trailed
MS: the amount of time stops between +i e -i are trailed after the insertion of the new customer i.
GT, ET,LT: Variables indicating the Actual, earliest and latest time for pickup or delivery
111
Figure 6-6-1 - Feasibility I Logical Workflow
112
Figure 6-2 - Feasibility III Logical Workflow
113
Figure 6-3 - Feasibility IV Logical Workflow (first part)
114
Figure 6-4 - Feasibility IV Logical Workflow (second part)
115
7 Acknowledgments
Even though the work is completely written and elaborated in English language, I do believe it
would be better for me to write this last part in Italian, otherwise I wouldn't be able to express my
feelings the way I want to.
Sebbene i ringraziamenti siano solitamente un breve paragrafetto sul fondo della tesi, appena
prima dell'ultima pagina, ci tengo a voler essere abbastanza esauriente (e verboso) anche perché
l'occasione di questo sudato traguardo si presta particolarmente bene.
Ringrazio il professor Guido Gentile per la sua immediata disponibilità nel farmi portare a
compimento questo lavoro e per la preziosa direzione nel suo svolgimento.
Ringrazio anche Alessandro e Marco che mi hanno sempre mostrato una grandissima
disponibilità, gentilezza e (sopra ogni cosa) Pazienza, anche in situazioni per loro particolarmente
stressanti. Ringrazio Domingo per avermi subito accolto con grande cordialità ed Agostino per
avermi introdotto nell’ambiente di PTV.
Ringrazio i miei genitori Agostina e Dino che grazie al loro duro lavoro di ogni giorno mi hanno
permesso di potermi concentrare sul mio studio senza dovermi preoccupare di altro, motivandomi
senza mai mettermi pressione ed al contrario affievolendo quella che spesso mi imponevo da solo.
Sono ciò che sono grazie a voi, la mia gioia più grande è potervi dedicare la conquista di questa
tappa.
Ringrazio Chiara per essere sempre stata al mio fianco, avermi retto nei momenti peggiori ed
avermi regalato tutti questi anni magnifici che non scambierei per nulla al mondo. Ti Amo.
Ringrazio mia nonna Assunta che mi ha fatto capire a suo modo e dall’alto della sua novantennale
saggezza i rischi di una vita senza sacrifici.
Ringrazio tutti i miei compagni di viaggio, sia della triennale che della magistrale. Siete il vero
motivo che mi ha spinto a rimettere piede in un’aula o in una biblioteca quando non ne avevo
alcuna voglia.
Ringrazio il mio gruppo di amici storici (sapete chi siete) con cui sono cresciuto, per avermi
regalato così tanti sabati sera, vacanze e momenti irripetibili. Ringrazio gli amici lontani per
avermi trasmesso tante belle vibrazioni nonostante i numerosi chilometri che ci separano.
Ringrazio anche gli amici che per la mia solita distrazione non riesco a sentire o vedere tanto
spesso quanto sarebbe giusto per la loro importanza nella mia esistenza. Sopportatemi.
116
Ringrazio tutto il gruppo meraviglioso di compagni di Colle per avermi fatto appassionare ad una
disciplina meravigliosa che mi aiuta ogni giorno a tirarmi su (letteralmente).
Ringrazio mio cugino Lorenzo per il prezioso aiuto dato durante lo svolgimento delle parti più
strettamente informatiche e Francesco per l’aiuto con la parte grafica. Ringrazio anche Olivia e la
sua famiglia per avermi sempre fatto sentire a casa.
Ringrazio Pete, Phil, Tony, David, Roger, RDJ, Thom, Johnny, Syd e quelli che ora non posso
ricordare.
Grazie soprattutto a chi ho dimenticato di nominare, per dimenticanza o timidezza.
117
8 Literature Index
Berbeglia et al. – Dynamic Pickup and Delivery Problems, European Journal of operational
research (April 2010)
Bodin – Routing and scheduling of school buses by computer, University of Maryland (1979)
Bodin et al. – An algorithm for Vehicle Routing with Time Windows constraints, University of
Miami, 1981
Bodin et al. – The multi-vehicle subscriber Dial-A-Ride problem, University of Maryland, 1982
Catta – Darp Manual, Sapienza University (2004)
Catta – Problemi di Dial-A-Ride, Sapienza university (2004 dissertation)
Charikar et al. – The finite Capacity Dial-A-Ride problem, Foundations of computer science (1998)
Cordeau, Laporte – Dial-a-Ride problem: models and algorithms, Springer science & Media
(2007)
Colorni, Righini – Modeling and Optimizing dynamic Dial-A-Ride problems, International
transaction in operational research (2001)
Daganzo – An approximate analytic model of many-to-many demand responsive
transportation systems, University of Berkley California (1984)
Fu – Scheduling Dial-A-Ride paratransit under time-varying, stochastic congestion, University
of Waterloo (2002)
Gendreau et al. – A tabu search heuristic for the vehicle routing problem, Management science
(1994)
Gendreau et al. – Stochastic vehicle routing, European journal of operational research (1996)
Gentile, Catta – DARP software Manual, Sapienza University (2004)
Grotschel et al. – Simulation studies for the Dial-A-Ride problem, (1999)
Hall et al. – A modelling system for simulation of Dial-A-Ride services, Linkoping university
(2012)
Hung et al. – Vehicle routing problem with time windows for perishable food delivering,
Journal of food engineering (2007)
Hvattum et al. - Solving a Dynamic and Stochastic Vehicle Routing Problem with a Sample
Scenario Hedging Heuristic, INFORMS (2006)
118
Jaw – Solving large scale Dial-A-Ride vehicle routing and scheduling problems, Massachusetts
Institute of Technology (PhD Thesis, 1984)
Jaw et al. - A heuristic algorithm for the multi-vehicle advance-request dial-a-ride problem
with time windows, Massachusetts Institute of Technology (1986)
Madsen et al. - A heuristic algorithm for a dial-a-ride problem with time windows, multiple
capacities, and multiple objectives, Annals of operational research (1995)
N. El-Sherbeny – Vehicle Routing with time windows: An overview of exact, heuristic and
metaheuristic methods, Journal of King Saud (2010)
Parragh,Cordeau – Models and algorithms for Heterogenous Dial-A-Ride problem with driver-
related constraints, University of Montreal (March 2010)
Pranzo – Appunti sul Vehicle Routing (2008)
Psaraftis et al. – Dynamic vehicle routing problems: Three decades and Counting, DTU (2018)
Psaraftis – A dynamic programming approach to single vehicle, many to many immediate
requests dial-a-ride problem, DTU (1980)
Psaraftis – An exact algorithm for the single-vehicle many-to-many dial-a-ride problem with
time windows, DTU (1983)
R.Larsen – Partially Dynamic vehicle routing: models and algorithms, Journal of the operational
research society (June 2002)
Russell – Hybrid heuristics for the vehicle routing problem with Time Windows, University of
Tulsa (1994)
European commission directorate for energy and transport - Synopsis of DRT
Toth, Vigo – The vehicle routing problem, Philadelphia (2002)
Toth, Vigo – Heuristic algorithms for the handicapped persons transportation problem, Boston
(1996)
Toth, Vigo – Fast local search methods for the handicapped persons transportation problem,
Boston (1996)
Wilson et al. – Advance Dial-A-Ride algorithms research project: final report, MIT (1975)
Wilson et al. – Scheduling algorithms for dial-a-ride systems. Technical report, MIT (1971)
Wilson et al. – Computer control of the Rochester Dial-a-Ride system. Technical report, MIT
(1976)
119
Sexton, Bodin. – The multi vehicle subscriber Dial-A-Ride problem, Elsevier science publisher
(1986)
Stein – Scheduling a Dial-A-Ride transportation system, Journal of transportation science (1978)
Woeginger – Exact algorithms for NP-hard Problems: A survey, University of Twente (2003)
