See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/225945037

An Integrated Framework for Bus Logistics Management: Case Studies

Chapter · July 2009

DOI: 10.1007/978-3-7908-2362-2_20

CITATIONS READS

12 926

4 authors, including:

József Békési Andrej Brodnik

University of Szeged University of Ljubljana
43 PUBLICATIONS 435 CITATIONS 117 PUBLICATIONS 1,651 CITATIONS

SEE PROFILE SEE PROFILE

Miklós Krész
University of Szeged
64 PUBLICATIONS 374 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Integrated Care - eCare View project

CaReWood View project

All content following this page was uploaded by Miklós Krész on 17 March 2014.

The user has requested enhancement of the downloaded file.

 An integrated framework for bus logistics
management: case studies ?

József Békési1 , Andrej Brodnik2 , Miklós Krész1 , and David Pash2

1
Institute of Applied Sciences
University of Szeged, H-6701 Szeged, POB 396, Hungary,
{bekesi,kresz}@jgypk.u-szeged.hu
2
University of Primorska, PINT,
Muzejski trg 2, Koper, Slovenia
{andrej.brodnik,david.pas}@upr.si

Abstract. This paper describes the most obvious way for public trans-
portation companies to decrease their operational cost. This is to opti-
mize the logistic of their operation. The optimization process is a very
complex operation and therefore we split the logistics into three phases:
vehicle scheduling, driver scheduling and driver rostering. The phases
reflect also the split of a large problem (long term optimization) to the
daily operation and finally to individual trips. The individual trips are
then grouped into working shifts and to these are scheduled individual
drivers.
In the paper we present a detail description of bus scheduling. We use
its mapping to the multiple depot vehicle scheduling problem (MDVSP)
using a time-space network model. Finally, we solve the problem for two
different cases – the city of Szeged and city of Ljubljana.

1 Introduction

The largest expense of public transportation companies are operational costs

which include cost of bus fleet, gasoline and maintenance of the fleet, and salaries
for the drivers. Therefore the reduction in operational costs represents a big
improvement in their OPEX. One of the most common ways to reduce the cost
is the introduction of an efficient computer supported integrated information
system.
Due to the development of ICT (information and communication technology)
nowadays a bus company has its own information system, ensuring a modern
business engineering environment. The main functions of these systems are, be-
sides business applications like accounting etc., also: preparing bus schedules for
lines served by the company, scheduling buses and drivers to serve the lines,
tracking and monitoring of bus fleet during the day and notifying the dispatcher
?
This research was partially supported by Szeged City Bus Company (Tisza Volán,
Urban Transport Division) and by the Hungarian-Slovenian Intergovernmental Pro-
gramme for 2008-2009 (project number BI-HU/08-09-012 )
2

in case of unusual events, track the mechanical performance of buses in a fleet

and similar.
Nevertheless, ICT environment is a basic background for the efficient logistic
management(e.g.[17]), but the second step is to discover the parts in the system
which can be optimized with respect to operational costs. There already are
several commercial decision support tools like IVU Microbus, INIT initplan, and
M.A.I.O.R. that aim to be a complete solution for the planning and optimization
of the logistic system. In practice, however, it turns out that there are several
company-specific constraints in real life that cannot be tackled by these general
purpose systems, but which are important for the computed results to be useful
for the bus companies. A typical example for the above situation is that most of
the buses in Szeged urban transportation (especially buses running on natural
gas) must be refuelled during the day what must be taken into account by the
scheduling software to create reasonable vehicle schedules and assignments.
Following the general method of the development of a bus operation service,
the main elements of a system are: bus routing, timetabling, scheduling of buses
and scheduling the drivers. The bus routing is usually defined by the city and the
bus companies usually have only a minor possibility to influence it. Furthermore,
cities also usually define the frequency (or capacity) of buses riding each line and
the bus companies have minor influence here as well. On the other hand, it is
completely up to companies to schedule their fleet of buses and roster of their
drivers.
Setting the mentioned elements represent one huge entwined problem requir-
ing a global optimization. However, such an approach is completely unfeasible
and hence we split it into sub-problems (see Fig. 1), which are isolated enough

Bus routing

Timetabling

Scheduling

Fig. 1. Stages of transport operations planning and scheduling

that we can tackle them in practice. Still, however, the planners and sched-
ulers do make changes back and forth among the tasks to find a more globally
optimized solution.
In this study we mostly theoretically concentrate on the scheduling of a bus
fleet, although we also describe the general structure of the bus logistic manage-
ment systems. Furthermore, based on the experimental results, we provide the
 3

necessary support for decision making on the other aspects of the system – driver
scheduling and driver rostering. The reason for giving a detailed insight into the
bus scheduling only is twofold. On the one hand – taking into consideration of
the space restriction too – the system integration of vehicle scheduling is com-
plete, providing us the opportunity to apply it for case studies in two different
cities. On the other hand – taking into consideration of the space restriction
–, vehicle scheduling is appropriate to serve as a proof of our concept for the
presented flexible system.
Scientific community recognized several decades ago that the optimization of
the above problems are challenging and exciting tasks. Several results have been
achieved ([4], [3], [5], [7], [15], [6]), concerning the model and the algorithms.
It turned out soon that most of the subproblems are NP-hard, which makes it
difficult to find an exact or a nearly exact optimum for larger problems. However,
even in a middle size city (few hundred thousand population), the problem is
quite complex.
The problem is even more complex if we consider all constraints originat-
ing from legislation, union agreements, personal requests, and other practical
issues. To avoid this additional complexity we developed a highly modular sys-
tem or better a framework which permits us inclusion of the above mentioned
requirements as necessary.
Consequently, since a general framework for bus logistics management is
difficult to describe because the companies and their activities differ significantly,
we decided to investigate two quite different cases. Hence, the main goal of this
paper is to present our experience through the case studies, which aspects are
important in forming such an integrated environment, and also present how
the mathematical results can be applied. The cases we choose are: Szeged3 and
Ljubljana4 . Both cities are middle sized cities, although Ljubljana has almost 300
thousand inhabitants, while Szeged has 160 thousand inhabitants. Furthermore,
since the two cities are in different countries, we could investigate the general
aspects of the problem, avoiding the situation that the developed system to have
too many national aspects.
The structure of the paper is the following: first we describe a scheduling
system for a public transportation companies in a greater detail. Next, we in-
troduce the model in which we will solve the problem and also present related
theoretical problems and subsequently, we describe how our solution fits into a
general framework for bus logistics management. The last two sections present
the practical results from the two case studies and give conclusions.

2 Scheduling systems for public transportation

Scheduling in public transport is a complex task, as it was outlined in the pre-
vious section. Considering the problem from operational point of view, theoret-
ically a global optimum is expected, which reduces the operational cost induced
3
www.szeged.hu
4
www.ljubljana.si
4

by both vehicle operations and personal scheduling. As the above-mentioned

cost types influence each other (more efficient vehicle scheduling may increase
the personal costs) newer approaches suggest a combined model that tries to
solve the vehicle and driver scheduling simultaneously (see eg. [23]). These mod-
els however are still under research and their computational complexity does
not allow for an interactive planning process. Moreover, in combined models
only a few general constraints for driver scheduling can be formalized, such as
the prescription of a mail break. However, in practice several specific constraints
need to be considered, like the type of the breaks might depend on the executed
working hours, the location or the structure of the particular schedule.
The above reasons convinced us to follow a more classical approach where the
vehicle and personal scheduling are treated separately. Moreover, in the design
of personal scheduling we distinguish two phases: driver scheduling and driver
rostering. The difference between the above subproblems is the following.
A driver schedule is a collection of the duties of one driver for a given period
(typically for one day) such that all the personal rules concerning the given
period are satisfied. Typical rules are breaks after a prescribed time, constraint
for the daily working hours etc. However, the constructed driver schedules are
assigned to particular drivers in the rostering phase only, when the duties of each
driver are obtained as a collection of driver schedules. Driver rostering generally
concerns a longer period, typically several weeks. In the rostering phase, all the
rules regarding the given longer period are considered, such as weekly rest day,
rest period between daily schedules etc.
The main reason of the above grouping of optimization subtasks is that these
subproblems are more tractable separately, meaning that mathematical mod-
elling can be better captured and the solution algorithms are more efficient. Now
we shortly describe the above subproblems and also summarize which aspects
are considered in the scientific papers and which further aspects are significant
in a practical logistic environment.
Vehicle scheduling
Vehicle scheduling problem consists of scheduling a fleet of vehicles to cover a set
of tasks at minimum cost. The tasks are given by prescribed time intervals and
vehicles are supplied by different depots. The problem is to minimize the total
cost induced by the number of vehicles used and by the vehicle travel (timetabled
and deadhead trips) length. There are several mathematical models for this
problem. The most widely used ones are when the problem is formulated as an
integer multi-commodity network flow model ([4], [15], [11]). In this model the
optimal schedule is computed by solving a linear integer programming problem.
There exist other formulations as well, for example set covering formulation (see
for example [21], [9]). The disadvantage of the models applied in the literature
is that only those rules are considered which relate to the timetabled trips, such
as the required bus type or bus capacity. However, it is not possible with the
above techniques to handle vehicle specific restrictions coming from real-word
applications. Typical vehicle specific constraints in transportation logistics are
refueling requirements, different maintenance regulations (weekly, monthly etc.)
 5

or parking rules (the possible parking places depend on the particular parking
length etc).
Driver scheduling
In driver scheduling there is a set of operational tasks and the aim is to define the
sequence of these tasks as shifts in such a way that every task must be assigned
to a shift with minimizing the cost. There are many constraints depending on
the transportation company and the relevant laws such as maximum number of
working hours, length of the daily break, number and length of short breaks, etc.
Since the costs of the tasks can be weighted according to the concerning pay-
ment, shift-costs can be calculated. Therefore, the objective of driver scheduling
is minimizing the complete cost of the scheduled shifts. The most favorite ap-
proaches are set partitioning and set covering as relaxation of the problem. There
are two ways of producing a solution: constructing one solution guided by the
constraints [7] or to generate a large set of candidating shifts and choose the
best one [13]. Many types of algorithm are used to solve the problem, e.g. inte-
ger linear programming [24], evolutionary algorithm [13] or fuzzy method [14].
Nevertheless, different companies have different driver scheduling policies, like
rules concerning the possible locations for changing drivers (relief points) etc.
Because of these differences and the high number of hard constraints, most solu-
tion methods deal with only a few basic constraints, such as maximum working
hours or handling some short and a long (meal) break. But in real-life case, the
schedule of breaks is not so simple: the number of the breaks may depend on the
length of the shift, there might be a high variation in the length of the different
break-types or there are special places where the breaks must be passed. More-
over there are bounds for not even working time, but driving time and other
prescribed activities. [8]
Driver rostering
In driver rostering there is a set of daily shifts as the output of the driver schedul-
ing and a set of drivers. The method produces an assignment of the persons to
the shifts for a planning period: several days, weeks, months or even a year. Gen-
erally there are usually some standard constraints such as the maximum number
of working hours per week or the minimum number of day off but these can be
totally different in different crew scheduling area (airline, train, urban transport,
nurse etc.). Nevertheless, usually many special local constraints are also applied,
such as there must be at least one Sunday as day off or there are several types
of driving license depending on the bus-types used. The cost of an assignment
highly depends on the controlling ”philosphy” of transportation company, typi-
cally it contains many components. The objectives can be the number of drivers
to be minimized, the number of buses used by a single driver to be minimized,
or the difference of the average working hours and the stated working hours in
the contract (overtime, undertime) to be minimized, etc. By this reason, some
methods are based on multi-objective rostering [19]. Since the main problem is
a general assignment, there are many general approaches for crew scheduling:
e.g. multicommodity flow [5], constraint logic programming [25] or evolutionary
method [19].
6

Considering the above subproblems, we can conclude that several options are
possible for designing the structure of a scheduling system. There are two main
questions which are important from the point of view of this structure:

– The ”border” between the rules of driver scheduling and rostering: The main
principle is that the personal regulations prescribed during a daily shift are
considered in driver scheduling, while other rules are the constraints of driver
rostering. Nevertheless, by the above approach, in theory we may obtain a
structure of daily schedules which cannot be assigned to the crew in a feasible
fashion. In practice, this worry is realistic only in the case of smaller compa-
nies, like the urban transportation of smaller cities (with population signif-
icantly below 100 thousand), because the smaller combination possibilities
may cause assignment problems in a predetermined schedule structure. How-
ever, in this case the problem size is much smaller, which makes it possible to
consider driver scheduling for week periods, reducing the risk of infeasibility.
Therefore, a compromise can be made by a quite simple methodology.
– The order between the driver scheduling and personnel scheduling: Since the
vehicle duties are prescribed by the timetable, it is quite a natural way to
find an optimal vehicle scheduling in the first phase, then the drivers are
assigned to the vehicles in such a way that – allowing vehicle exchanges dur-
ing the shift – all the personnel rules are satisfied. According to the logistic
paradigm, the above methodology is efficient, but takes robust computational
optimization background. Therefore, in practice, where the computational
support does not include optimization tools, the engineering ”heuristics” as
a first step construct driver schedules for the timetable with taking into con-
sideration the personnel rules, then appropriate vehicles are assigned to the
driver schedules. The advantage of this latter approach is that the prob-
lem complexity is significantly reduced, since vehicle exchange is not allowed
during the shifts. However, as a quite disadvantageous aspect the above re-
duction might result in schedules with higher costs. (Typically the number of
buses used in a single day is significantly higher) Therefore, an optimization-
oriented automatic scheduling system is supposed to follow the principle of
starting with vehicle scheduling.

Summarizing the above facts, considering both the practical and theoretical
(mathematical modelling etc) aspects for designing a well-established scheduling
system, the general view of the structure is represented in the following figure:
A typical action for a scheduling system is applied for a longer period (several
weeks or months). Therefore, the stream in the process represented in Figure 2
is considered in a way that vehicle scheduling and driver scheduling are repeated
for each day of the particular period and a phase of driver rostering is applied
for a related scheduling term prescribed by general or local rules. Nevertheless,
as it was earlier mentioned, in (theoretical) vehicle scheduling several impor-
tant practical aspects cannot be modelled. In the following we present how we
modified this structure in order for these aspects are also considered.
 7

Vehicle scheduling

Vehicle assignment

Driver scheduling

Driver rostering

Fig. 2. Structure of the scheduling system

Based on the above observations, our scheduling system consists of four mod-
ules: vehicle scheduler, vehicle assignement, driver scheduler, driver rostering.
Below we summarize the tasks of each module.
Vehicle scheduler: In this module, the classical vehicle scheduling problem
is solved for each day of the considered period. The vehicles are grouped into
depots according to their characteristics and/or their location. The number of
available buses provides a constraint for each depot. The buses in the same depot
are considered identical with respect to their general and operational costs, and
for each trip it is prescribed which depots can serve it. Using the above data,
the algorithm gives an optimal solution with respect to the sum of the costs
such that all the trips are accomplished. The result of this module is a set
of vehicle schedules, such that each schedule is labelled with a depot and it
consists of trips which can be served from that particular depot. However, no
real vehicles are assigned to the schedules and the duties concerning real vehicles
(fueling, maintenances, parking) are not contained in the schedules. As a solution
methodology, we apply a time-space network model ([11]) which is a modern
approach in the classical multi depot vehicle scheduling problems.
Vehicle assignement: Making use of the schedules of the previous phase,
this module is responsible for a real-life daily schedule of the given vehicle set
such that all the vehicle-specific demands (refuelling, parking, maintenances)
are satisfied. In this approach we apply an assignement model ([1]) in which
both the matching between the schedules and vehicles are executed and the
vehicle-dependent duties are inserted into the schedules in a simultaneous fash-
ion. The feasibility depends on both the allowed schedule-vehicle assignements
(e.g. vehicle-schedule pairs must have the same depot property) and the real-
izable vehicle-duties (e.g. the number of vehicles at a filling station in a given
time-window cannot exceed the station capacity). The complexity of the above
8

problem is arising from the simultaneous approach, but a sequential solution of

these two subproblems might result in infeasible situation.
Driver scheduler: In this part, the input data come from the vehicle scheduler
and vehicle assignment modules. The aim is to partition these tasks into sets
for a single day such that these sets satisfy all the constraints induced by the
daily rules. The main considered daily rules are the followings: upper bounds
for driving time, for the working time and for the length of the shifts. Moreover,
there must be required number and length of breaks in a scheduled time-window
and every prescribed activities (administration, maintenance, etc.) are included.
The aim of the optimization is to minimize the total cost of the shifts. This cost
also can be quite different depending on the company. Basic claim is to minimize
the number of shifts, but even the cost of a single shift might be weighted by
the length of the working hours, the length and position of the inactive periods
and the type of the activities. Methodologically we apply a new approach ([10])
in which an initial semi-solution is constructed by an adaptation of the time-
space network model for drivers, than by a heuristic we iteratively cut-and-match
the solutions with respect to work units, resulting a gradually improved result
according to a cost function based on the proportion of active and inactive time
shifts.
Driver rostering: In this phase the aim is to assign real drivers to the con-
structed shifts for a planning period (some days, weeks, months) fulfilling the
rules and minimizing the total cost. The constraints can be also quite different
by customers, but usually they apply the rest days, number of working hours
and number of hours between two consecutive shifts. Of course, there can be
local rules e.g. one resting day must be a Sunday. Another difficult problem is
the ”human-depot” which means that a driver can be assigned to a task iff he
has the suitable driving license concerning that vehicle. A shift, coming from the
driver scheduler module is ”labelled” by the set of the driving licenses expected
from the assigned person. The main goal is to minimize the number of required
drivers, but the cost may also contain the penalized number of overtime and
undertime hours. Since driver rostering is not bus driver specific problem, we
use classical approaches from the rostering literature.
In this paper we present a detailed description of the vehicle scheduler module
and its application experience in two middle-size cities. Therefore, the case study
objective of our paper is twofold: On the one hand, through the vehicle scheduler
module, we present our development approach for the integration of theoretical
result in real-life information technology environment in urban transportation
logistic management. On the other hand we analyze the usage of our system in
two similar size cities with different operational environment (different countries,
differences in current logistic approaches in everyday operation)
Finally, with the help of the vehicle scheduler module, we also present the
high modularity of our system. We will review how the modules can be applied
separately in the operation management process, and as a third ”case study”
give a detailed methodology for the use of vehicle scheduling in decision support.
 9

3 The Multiple Depot Vehicle Scheduling Problem

In this section we present the mathematical model applied in the vehicle sched-
uler module. Since in the general case, based on the special demands of the
timetabled trips and the physical locations of the buses, the vehicles are sepa-
rated into depots in a natural way, we concentrate on the multi depot problem.
The Multiple Depot Vehicle Scheduling Problem was defined by Bodin et al.
[4] and was shown to be NP-hard by Bertossi et al. [3] The model represents the
most important components of the real-world problem. Our terminology follows
the terminology used by Löbel. [15] The two most important components are the
set of timetabled trips and the set of vehicles. We call timetabled trips those ones,
when the vehicles carry passengers. All trips are represented by their departure
and arrival time, stations, and their distance. The set of available vehicles can
be classified by their location, i.e. the garage where the vehicles are parked. The
vehicles may have some other specific properties, for example low-floor, double-
decked, etc. This allows us to make further classification on the set of vehicles.
Based on these properties and the physical locations we can make several subsets
of the vehicles, which are called depots.
In addition to the timetabled trips, the vehicles have to execute other kind
of trips. For example they have to travel from the parking place to the starting
station of their first trip. In this case they do not carry passengers and so we
distinguish these kind of trips from the timetabled trips. We call them deadhead
trips. Typical deadhead trips are the ones when a vehicle travels from or to
its parking place, these are called pull-out and pull-in trips respectively. More
deadhead trips are possible, for example when a vehicle changes station after
executing a trip, in order to work more efficiently.
For each timetabled trip the user specify the set of depots, from which it can
be executed. In practice this means for example that certain trips can only be
executed by double-decked vehicles from given garages. These kind of conditions
are very reasonable, taking into account the garage and station locations and
traffic characteristics.
We can define some relation between the timetabled trips. We say that two
trips are compatible, if the vehicle is able to arrive in time to the location of the
second trip after executing the first one. If the arrival station of the first trip is
the same as the departure station of the second one, then the only condition of
the compatibility is that the arrival time of the first trip is smaller or equal than
the departure time of the second trip. Otherwise we have to take into account
the time of the deadhead trip between the stations. We assume that the pull-out
and pull-in trips are always compatible. We have already used the term of vehicle
schedule, but now we can give a more precise definition. A vehicle schedule is
a chain of trips, where each timetabled trips is compatible with the next one.
Usually in practice a vehicle schedule represents a daily work of a vehicle. The
first trip of a valid vehicle schedule should be always a pull-out trip and the
last one should be a pull-in trip. Other deadhead trips may occur between the
timetabled trips.
10

The basic multiple depot vehicle scheduling problem (MDVSP) is to construct

the minimal number of vehicle schedules in such a way, that each trip is assigned
to exactly one schedule and all trips in a given schedule can be executed from
a given depot. Instead of minimizing the number of vehicles it is possible to
define a cost function and minimize it. The cost function should represent the
total cost of the schedule. In this latter case, we can distinguish for each depot
a vehicle general cost (cost arisen from the ”existence” of an average vehicle of
the given depot) and a vehicle operational cost (cost proportional to the traveled
distance). Moreover, the presented models are capable to handle ”depot capacity
constraints”, i.e. the solution takes into consideration the maximum number
available vehicles in each depot. Though the developed system uses the above
extensions in the optimization, for simplicity we omit them in the description of
the models.
In the following we are presenting two solution techniques for the MDVSP
problem. Both of them transform it to a multicommodity flow minimization
problem and solve it as an IP problem. The difference between them is the
construction method of the basis network. The models are called connection
based and time space network models. There exist other formulations as well,
for example set covering formulation (see for example Ribeiro & Soumis [21] or
Hadjar et al. [9] ), but we do not deal with this here.

The connection-based multicommodity network flow model

This model has been widely used to solve the problem and a lot of research has
been focused on this technique. Researchers mainly dealt with the improvement
of the solution methods for the IP problem and with different formulations.
Some approaches are based on heuristic methods ( see Löbel [15] , Dell’Amico,
Fischetti, and Toth [6] , Mesquita and Paixao [18]) others deal with exact algo-
rithms (see Kokott and Löbel [12], Löbel [16]). Several heuristic approaches are
investigated and compared by Pepin et al. [20]
To describe the model we introduce some notations. Let D denote the set
of depots and T the set of trips. For each t ∈ T denote by d(t) and a(t) the
departure and arrival time of t respectively. Denote by g(t) ⊆ D the depot set
of t, which means that only a depot from this set is allowed to service trip t. Let
Td ⊆ T is the set of those trips, which can be serviced from depot d. Similarly
for every d ∈ D we define by s(d) and e(d) its starting and ending point. The
set of the nodes of the corresponding network is defined by
N := {d(t) ∪ a(t) ∪ s(d) ∪ e(d)|t ∈ T, d ∈ D} .
We define the edges of the network as well. Let
Ad := {(d(t) , a(t))|t ∈ Td }
the set of timetabled trips corresponding to the depot d.
Let n 0 0
o
B d := (a(t) , d(t ))|t, t ∈ Td compatible trips
the set of possible deadhead trips corresponding to the depot d.
 11

Let
P d := {(s(d) , d(t), (a(t), e(d))|t ∈ Td }
the set of pull-out and pull-in edges corresponding to the depot d.
From this we can give the set of edges of the network.

E := Ad ∪ B d ∪ P d ∪ {(e(d), s(d))} for all d ∈ D,

where (e(d), s(d)) are the so called depot circulation edges necessary for the
correct definition of the network.
Now we are ready to define a feasible solution of the MDVSP problem on
the network (N, E). To do this, we define an integer vector on the edges of the
network, which can also be considered as a multicommodity flow. Denote this
vector by x. We have to define such constraints on x, which assure the basic
requirements of the problem. If a component of a vector belongs to the edge e
of depot d, we simply write xde . The constraints are that each trip should be
executed exactly once and the solution is disjoint chains of trips. Formally they
look like this X
xd(d(t),a(t)) = 1 for all t ∈ T, (1)
d∈g(t)

X X
xde − xde = 0 for all d ∈ D and n ∈ N, (2)
e∈n+ e∈n−

xde ∈ {0, 1} except for the depot circulation edges, (3)

xde integer, (4)

where n+ denotes the set of outgoing edges from node n and n− denotes the set
of incoming edges to node n.
Constraint 1 expresses that each trip should be executed once, while con-
straint 2 means that if a vehicle from a given depot arrives at a station, then
it should leave from that. If we have depot capacity constraints, we can add
them to the depot circulation edges as upper bounds on their flows. Any flow
satisfying these constraints is a feasible solution of the problem. If we want to
find an optimal solution, we should define an objective function. This can be
done by assigning weights to the edges, which represents the cost of that trip.
If we simply want to minimize number of vehicles, we should assign relatively
large weights to the pull-out edges. If ce is the cost of edge e, then the objective
function is X
ce xe ,
e

and we want to minimize it. This defines an integer programming problem. The
problem is that usually there are a lot of edges in the network, even for real
problems given by transportation companies of smaller cities. To decrease the
number of edges a new model has been developed.

The time-space network model

12

This model has been developed by Kliewer at al. [11] and it enables us to solve
MDVSP problems with practical sizes. The main disadvantage of the connection
based model, that usually the number of edges representing deadhead trips is
extremely high. This is because there are a lot of theoretically possible dead-
heads. In the final solution we use only a small percent of them, but it is not
possible to leave any of them, because in this case we can loose the optimality
of the solution.
To overcome on the above problem, Kliewer et al introduced the time-space
network model. In this model there are two dimensions, time and space. Actually
space means existing physical locations or stations, while time is represented
by timelines, which belong to stations. Timelines contain the departure and
arrival times. Each possible departure and arrival time point means a node on
its timeline. It is easy to see that the main difference between the two models is
that in this one the time points are assigned to locations. So we can define the
set of nodes N of the network as the possible departure and arrival times for all
stations. We can define Ad similarly as in the previous model for every d ∈ D.
Of course there are timelines also for the depots, so it is possible to define P d .
See Figure 3 for a sample time-space network.

Fig. 3. A sample time-space network

Another main difference between the two models is the definition of the
deadhead trips. In the timespace network model it is possible to use timelines,
which can aggregate the flows of some possible deadhead or trip edges. So it
is not necessary, to explicitly give all the possible deadhead edges. By using
 13

an aggregation strategy the number of edges can be reduced drastically. The

authors define the so called latest-first match strategy. The basic idea of this
is a two-stage aggregation procedure. In the first stage for each arriving trip
edge the first compatible deadhead edge is computed for each other station.
These edges are called first matches. Only these edges are considered among the
possible deadhead edges. In the second stage these edges are further reduced.
The technique is to introduce the latest first matches. The idea is to collect the
incoming trip edges at a given station with the same first matches on another
station. Then instead of all the common first matches only the latest one can be
considered. This is called latest first match and omitting the other first matches
makes possible further decreasing of the edges. So we can define B d as this
reduced set of deadhead edges. To complete the model we have to add a set of
waiting edges W d for each d ∈ D. These edges follow always the timelines and
connects the subsequent time points aggregating the flows along the timelines.
So in this case the definition of the set of edges E is

E := Ad ∪ B d ∪ P d ∪ W d ∪ {(e(d), s(d))} for all d ∈ D.

The IP model is similar for this network, except that we should substitute the
xde ∈ {0, 1} condition with xde ≥ 0.

4 Integration of the scheduling software component into

bus logistics management systems
As it was earlier mentioned, the scheduling software component has 4 modules:

– vehicle scheduler module

– vehicle assignment module
– driver scheduler module
– driver rostering module

Each module is based on the previous one and directly uses its output as an
input. The schedules of the first module are the input of the vehicle assignment
module. The vehicle assignment module assigns buses to the schedules, schedules
refuelling, adds parking events, calculates bus service times, etc. This module
requires further parameters, for example refilling frequency requirements, park-
ing rules, service times, etc. The module applies an assignment algorithm, which
is described in detail in [1]. The driver scheduler and rostering modules use the
vehicle schedules as input and it assigns drivers to them using the driver working
rules applied by the company. Nevertheless, each module can be used separately
as well, an interface is provided for both the vehicle related and driver related
tables through which one can load the inputs in the appropriate format. For
example, after running the vehicle assignment module, the manager has the op-
portunity to modify the schedules and assignments, and then driver scheduling
is applied with the modified data. The following figure shows the structure of
the system.
14

Timetable
Vehicle database Vehicle schedules Vehicle assignments
Driver database Vehicle database Driver database

Driver scheduler,
Vehicle scheduler Vehicle assignment Driver rostering
module module modules

Operational
Vehicle schedules Vehicle assignments
management tools

Fig. 4. The structure of the integrated scheduling system

In the following we introduce the bus scheduler module in details. The fun-
damental solution model integrated is the MDVSP based time-space network
solver. The necessary data for the MDVSP solvers usually can be obtained from
the information systems of the transportation companies. The most important
information are the timetable, depots, stations, and possible deadheads. To be
able to use an MDVSP optimizer we need at least the followings:
TIMETABLED TRIPS data table, contains all the trips defined by the timetable
for a day.

– TRIP ID : Identifier of a timetable trip

– DEP TIME : departure time of the trip
– ARR TIME: arrival time of the trip
– DEP STATION : reference to the departure station of the trip
– ARR STATION : reference to the arrival station of the trip

DEPOT TRIP RELATIONS data table, contains the possible trip depot re-
lationships

– TRIP ID : Identifier of a timetable trip

– DEPOT ID: Identifier of the corresponding depot

STATIONS data table, contains the possible stations

– STATION ID : Identifier of a station

– STATION NAME: Name of a station, only for information purposes

DEADHEADS data table, contains the possible deadheads

– DEP STATION : reference to a departure station

 15

– ARR STATION : reference to an arrival station

– TIME: deadhead time
– COST: deadhead cost

DEPOTS data table, contains the possible depots

– DEPOT ID: Identifier of the depot

– DEPOT COST: Average usage cost of a vehicle from that depot

The model can be built from this data. In our program we used the time-
space network model. To build the network, the following structures must be
given:

– the time lines with the departure and arrival time points, which will be the
nodes of the network,
– the trips edges, pull-out, pull-in and depot circulation edges for each depot,
– the deadhead edges for each depots,
– the waiting edges for each depot.

The following submodules are distinguished:

– input/output submodule,
– time-space network building submodule,
– solver submodule,
– output generator submodule.

Time lines can be easily built by using the TIMETABLED TRIPS and STA-
TIONS data tables. The number of time lines will be given by the number of sta-
tions and for each station we should generate the ordered departure and arrival
time points from the TIMETABLED TRIPS table. Here we handle the situation
when a time point is a departure and an arrival time as well. We should add a
time line for each depot with artificial departure and arrival times as well. Trip,
pull-out and pull-in edges are also generated from the TIMETABLED TRIPS
table. We use the DEPOT TRIP RELATIONS table to decide for which depot
we need add an edge. Here we can order the DEPOT COST value to each cor-
responding pull-out edge. Finally, we add the waiting and deadhead edges based
on the DEADHEADS table.
For solving the generated problem we included the IP solver SYMPHONY
5.1.7. The output generator submodule simply reads the solution from the solver
and build the bus schedules from the edges of the solution. It simply creates the
chains by parsing the network edges based on the solution values.
The sets of the module make it possible to use the system both for operational
goal and for logistics analysis. As it was outlined in Section 3, the time-space
network model can be equiped with constraints for depot capacity. If the system
is used with the constraints provided by the status of current vehicle set, then
the system is used for operational goal. In this case, the schedules can be con-
structed effectively with respect to the current company environment. However,
16

if the above constraints are systematically modified, then the same module is
iteratively used as a decision support tool for structural and logistics analysis in
the operations of the company. For example, one can analyze, which collection of
the different bus types could offer the most efficient service level. For the above
analysis, the module should be applied without depot capacity constraints. Nev-
ertheless, by a more sophisticated way, simulations can be executed for different
situations of the bus collection. The flexibility expressed by the above described
multi-functionality (scheduling and analysis) is one of the main advantage of the
developed integrated solution.
The second main novelty of the system is the modularity in vehicle schedul-
ing. Though the results of the vehicle scheduler module gives only raw schedules,
but by our new approach (cf. [1]), in the vehicle assignments module, these sched-
ules can be used as a starting point for the design of the real vehicle operation. In
real-life vehicle operation there are two additional main aspects not considered
in the vehicle scheduler:

– The vehicle schedules must be physically assigned to a real bus.

– The vehicle schedule contains several further special duties.

The above twofold objective results in a series of optimization problems,which

can be solved by the vehicle assignments module. Since this phase might be
quite different in the practice of the companies, a typing methodology have been
developed for the grouping of the vehicle-specific tasks. By our methodology,
four types of vehicle-specific tasks can be distinguished which are solved by this
module as subproblems:

– Physical depots: The vehicle scheduler does not determine the starting and
terminating geographical locations of the vehicles.
– Parking places: If there is a break between two tasks, then the vehicle is
parking in some location. Since each location has a strict parking regulation,
the parking places must be also determined for each breaking time in all
schedules
– Refuelling schedule: Based on the distance capacity and the actual fuel level,
the vehicles must be scheduled for refuelling. The schedule also needs to take
into consideration the capacities of the service stations.
– Maintenance: Regular maintenance is needed for each vehicle. Generally
there is a frequent maintenance type (approx. weekly), an in-depth main-
tenance type (approx. monthly) and a grand technological service (approx.
yearly). All the maintenances are scheduled, their constraints are similar to
the refueling service.

All the necessary models in the vehicle assignments module can be built
from the tables used by the vehicle schedulers. Concerning the cost function,
the coefficients represent individual vehicle costs, unlike in the case of vehicle
scheduler, where average costs of the depots are considered. As a result, the
”vehicle part” provides a complete real-life vehicle schedule for the ”driver part”
of the system.
 17

5 Computational results in Szeged

The Szeged City Bus Company5 operates 40 lines, the total length of the lines
is 328 km and served by 120 buses and about 160 drivers. The frequency of the
trips depends on the day of the week (working day, saturday, sunday or holiday)
and the time of the year (summer period, school time, etc). The buses run
between 100 and 500 km on a working day. They have a predefined schedule,
which consists of a series of trips. In addition to the trips some other events
may happen during the day. For example, most of the vehicles are needed to
be refilled. Parking is allowed only on predefined parking centers, so if a vehicle
should wait for a longer time, then it has to travel to its parking centrum.
Deadhead trips are also allowed and usually applied to make the bus schedules
more efficient.
We have tested our bus scheduling system on the real-world data received
from Szeged City Bus Company. The database of the largest timetable contains:

– 2700 trips,
– 4 vehicle-types and one physical depot,
– 120 vehicles.

We applied our program for 14 different subproblems, which came from dif-
ferent timetable versions of the transportation company. These versions were
applied for different days, for example weekdays, weekend, etc. The following
tables contain the most important characteristics of the 14 problems.

Problem Trips Depots IP rows IP cols Buses (program) Buses (current)

1 2765 4 18186 180151 97 107
2 2765 4 18186 180151 96 107
3 2767 4 18196 180563 96 107
4 1826 4 12687 122113 51 57
5 2033 4 14355 136791 59 67
6 2033 4 14355 136791 59 67
7 1827 4 12697 122211 51 57
8 1822 4 12652 121045 51 57
9 2767 4 18196 180563 97 107
10 2765 4 18186 180151 96 107
11 2758 4 18143 179349 94 107
12 1821 4 12643 120947 51 57
13 2760 4 18153 179761 94 107
14 2758 4 18143 179349 94 107

Table 1: Results of the Szeged test data

It can be seen that the program could achieve a significant reduction – almost
11 % in average case – in the number of necessary vehicles. Nevertheless, it is
5
Tisza Volán, Urban Transport Division, www.tiszavolan.hu.
18

a realistic request to analyze the correlation of operational costs and general

costs, because the reduction on the number of buses my increase the length of the
deadhead trips. As it was mentioned in Section 3, the studied models of MDVSP
can be used for the above analysis, since they capture the optimization of the
total vehicle-type cost induced by the combination of general and operational
costs.
Taking advantage of the previously mentioned properties of the time-space
network model, we have executed basic running tests with respect to total vehicle
costs on the 14 subproblems. Though our results are quite reassuring (5%-10%
cost reduction), the used data can be considered only approximate, the realis-
tic cost determination takes further intensive cooperation with the controlling
department.
The results of vehicle scheduling can be ”justified” by its use in the vehicle
assignment and driver scheduling modules. Below we summarize our preliminary
experiences with respect to the above subproblems.
For the vehicle assignment task we applied our vehicle assignment algorithm
described in [1]. The following table shows the results.

Problem Trips Depots IP rows IP cols Objective Running time(sec.)

1 2765 4 702 183986 3016370 9
2 2765 4 696 187807 2944730 7
3 2767 4 692 184629 2930364 9
4 1826 4 540 50200 1803723 1
5 2033 4 572 90466 2006394 1
6 2033 4 572 90265 2008205 1
7 1827 4 536 50166 1808116 1
8 1822 4 546 52038 1806006 1
9 2767 4 692 184359 2913963 6
10 2765 4 694 189324 2921190 6
11 2758 4 690 169618 2903435 6
12 1821 4 558 51463 1811220 1
13 2760 4 690 175203 2897050 6
14 2758 4 690 173622 2898044 6

Table 2: Vehicle assignment IP model problem sizes and running times

Table 2 shows that the assignment model is very effecient, the running times
are very good even for larger problems. The model can effectively extend the
capabilities of the MDVSP models to be able to handle real vehicle assignment
with refueling and maintenance constraints. Apart from efficiency, it is also a
main point that the output of the vehicle scheduling module can be used to
construct feasible assignments on all of the real problem instances.
Several times, in practical applications a significant cost reduction in the
vehicle scheduling might result in extra costs in the driver scheduling phase.
Therefore it is an important aspect in justification of our concept is to test
 19

thoroughly on driver scheduling too. Our preliminary results show that though
our concept increases the number of driver schedules, but in cost there is a further
reduction. For example, in a typical working day, the present solution provided
by the Szeged Urban Bus Transportation ensures 164 shifts, while our algorithm
results in 172 shifts. However, in cost the system guarantees 3% reduction.
Finally, we analyzed the efficiency of the result with respect to logistics man-
agement point of view. For simplicity, we present our results concerning a prob-
lem induced by a typical working day. The statistics represented by Figure 5
gives a constraint for the necessary number of vehicles in a whole day timeline.

Fig. 5. Maximum number of parallel trips in Szeged

It can be seen that the maximum number parallel trips in a working day in the
worst example is 96. This is theoretical lower bound on the necessary schedules.
Our largest schedule uses 97 vehicles, which is very close to the lower bound.
Therefore, as a reverse analysis, we obtain that a significantly more efficient
timetable cannot be designed without increasing the vehicle cost.

6 Computational results in Ljubljana

The Ljubljana Public Transport6 serves 21 lines and some lines have during the
day variations (e.g. night ride, two switching end stations, etc.). The total length
of all lines is 263 km and are served by 207 buses and 376 drivers (numbers are
from June 2008). In the urban part of Ljubljana, 95% of all homes is in a range
of 500m from the closest bus stop. In 2007 the buses traveled for 12.5 million
km and served more than 96 million passengers.
6
Ljubljanski potniški promet, LPP, www.lpp.si.
20

The frequency of serving individual lines depends on the time of the year
(Spring or Fall, Summer and Winter), on day of the week (working day, Saturday,
Sunday or holiday) and also varies during the day. The daily variations follow
morning and afternoon rush hours and some other time of the day dependent
necessities.
Motivated by the results in Szeged we were looking forward to applying the
optimization software to Ljubljana. We managed to gain the cooperation of the
bus company that provides us with realistic test data. Like Szeged Ljubljana is a
mid-sized city, but is twice as big and currently also employs the double number
of buses. In this investigation we are also interested in how this scale factor of
two will express itself in the achievable gain and the problem complexity. In the
table below is given some statistical information about the used test data that
covers most of the urban bus traffic and the results of our computation. Of the 21
bus lines have been considered 18 that accumulate to 2482 individual passenger
trips. Additionally, computations have been also performed for the schedules for
Saturdays and Sundays/holidays. Deadhead trips have been calculated for all
pairs of end stations. Like in Szeged the computations have been performed on
standard, commodity hardware.

Problem Trips Depots IP rows IP cols Buses (program) Buses (current)

work. 2482 1 21178 250896 126 152
Sat. 1710 1 15070 181932 75 97
Sun. 993 1 8733 75960 64 82

Table 3: Results of the Ljubljana test data

If virtually no deadhead trips are used the software needs 152 buses to cover
the normal schedule. This closely resembles the present practice of the company
which uses deadhead trips mainly for exceptional situations. The relatively big
reduction in the number of buses through the incorporation of deadhead trips
into the regular schedule is promising and has increased the company’s interest
into the research.
Comparing with the data from Szeged you will notice that although Ljubljana
is about twice as big in size and has the double number of buses employed
there are about the same number of passenger trips. Thus computationally the
Ljubljana case is not really more difficult than Szeged’s. The reason for this is
that the bus lines in Ljubljana are much longer than those in Szeged and are
typically running from one end of the city to the other. This also hinders the
optimization software to achieve savings through the reassignment of the buses
to the lines.
The public transportation company has already expressed its will to redefine
the lines and to split them into smaller pieces yielding more and shorter bus
lines. This would give the optimization software more flexibility in combining
different bus lines what would result in bigger savings.
Further, it shall be noted that only one depot has been used here, multiple
depots that actually make the MDVSP difficult to solve will be included in the
 21

new, refined test data. Thus these results are not to be taken as the last word,
but only represent the current state of our research.
Figure 6 shows the number of parallel trips in a workday. The maximum lies
at 116 what is the theoretical optimum for a schedule. Our value of 126 thus
proofs to be a good result. Nevertheless, the above difference shows that there
might be some spare in designing more efficient timetabling without significantly
increasing the vehicle costs.

Number of parallel trips in a workday

140

120

100
Number of trips

80

60

40

20

0
0:00 1:01 2:02 3:03 4:04 5:05 6:06 7:07 8:08 9:09 10:10 11:11 12:12 13:13 14:14 15:15 16:16 17:17 18:18 19:19 20:20 21:21 22:22 23:23
Time

Fig. 6. Maximum number of parallel trips in Ljubljana

7 Conclusions

In the paper we presented how to build a modular bus logistic management

system. Its main building blocks reflect the usual stages (vehicle scheduling,
driver scheduling and driver rostering), but as a new approach, the refinement
in the modularization of the vehicle scheduling part makes it possible to vehicle-
specific practical aspects (refuelling, parking, maintenance) are also considered.
We showed that the solution to the classical vehicle scheduling problem can be
used as an input to the company-specific environment where vehicle assignment
is performed. Consequently, this shows that vehicle scheduling can be used as a
separate module in real life.
Furthermore, the presented methodology shows us how the vehicle scheduler
module can be used for operational goals and also for the logistics analysis.
22

By the logistics analysis is meant adjusting the constraints like depot capacity,
vehicle fleet, timetabling, etc.
To solve the vehicle scheduling problem we used a time-space network model
based solution of the multiple depot vehicle scheduling problem. The solution
uses an integer programming approach. We applied our algorithm to two different
cases: Szeged and Ljubljana. In both cases we observed a substantial possibility
for the improvement in the operational costs. However, we observed that it is
hard to improve the bus schedule when the lines (routes) are longer. This proved
to be the case in the Ljubljana situation. However, this observation might in-
fluence the company to re-think the structure of routes – yet another example
of the logistic analysis. We ran the program on a commodity computer and the
solution was computed in a reasonable time.
Our future work includes solving other stages mentioned above. The compa-
nies were particularly interested in the logistics analysis and this shall be one of
our next main focus of work. On a more technical part we intend to test the re-
sults using different IP solver and also parallelization of the program in a GRID
environment.

References
1. Balogh, J., Békési, J., Galambos, G., Krész, M.: Model and Algorithm for a Vehicle
Scheduling Problem with Refueling, in Proceedings of the 9th Workshop on Models
and Algorithms for Planning and Scheduling Problems, 2009, to appear.
2. Banihashemi, M., Haghani, A.: Optimization Model for Large-Scale Bus Transit
Scheduling Problems, Transportation Research Record 1733, PaperNo. 00-0738
3. Bertossi, A.A., Carraresi, P., & Gallo, G.: On Some Matching Problems Arising in
Vehicle Scheduling Models. Networks, 17, 271–281., 1987.
4. Bodin, L., Golden, B., Assad, A., & Ball, M.: Routing and Scheduling of Vehicles
and Crews: The State of the Art. Computers and Operations Research, 10, 63–
211.,1983.
5. Cappanera, P. and Gallo, G.: A Multicommodity Flow Approach to the Crew
Rostering Problem, Operations Research 52, 583–596, 2004.
6. Dell Amico, M., Fischetti, M., Toth, P.,: Heuristic algorithms for the multiple depot
vehicle scheduling problems. Management Science 39, 115–125., 1993.
7. Dias, TG, De Sousa, JP, Cunha, JP : Genetic algorithms for the bus driver schedul-
ing problem: a case study, Journal of the Operational Research Society, 53, 324–335,
2002.
8. European Union. 2006. Regulation (EC) No. 561/2006 of the European Parliament
and of the Council of 15 March 2006 on the harmonisation of certain social legisla-
tion relating to road transport and amending Council Regulations (EEC) 3821/85
and (EC) 2135/98 and repealing Council Regulation (EEC) 3820/85. Official Jour-
nal of the European Union L 102, 11.04.2006.
9. Hadjar, A., Marcotte, O., & Soumis, F. : A Branch-and-Cut Algorithm for the
Multiple Depot Vehicle Scheduling Problem. Tech. rept. G-2001-25. Les Cahiers
du Gerad, Montreal, 2001.
10. I. Juhos, M. Krész, A. Tóth: Combination of Exact and Heuristic Methods to
Solve Large Scale Driver Scheduling Problems, in Proceedings of the XXVIIIth
Hungarian Operations Research Conference, 2009.
View publication stats

23

11. Kliewer N., T. Mellouli, and L. Suhl : A Time-Space Network Based Exact Opti-
mization Model for Multi-Depot Bus Scheduling. European Journal of Operational
Research, 175, 1616-1627,2006.
12. Kokott, A. and Löbel, A. : Lagrangean Relaxations and Subgradient Methods for
Multiplie-Depot Vehicle Scheduling Problems. ZIB-Report 96-22, Konrad-Zuse-
Zentrum für Informationstchnik, Berlin, Germany,1996.
13. Kwan, R. S. K., Kwan, A. S. K., Wren, A. S. K.: Evolutionary Driver Scheduling
with Relief Chains, Evolutionary Computation, 9, 445–460.
14. Li, J: A Self-Adjusting Algorithm for Driver Scheduling, Journal of Heuristics, 11,
351–367, 2005.
15. Löbel, A.: Optimal Vehicle Scheduling in Public Transit. Ph.D. thesis, Technische
Universitaet at Berlin., 1997.
16. Löbel, A.: Vehicle Scheduling in Public Transit and Lagrangian Pricing. Manage-
ment Science 44, 1637–1649., 1998.
17. Meilton, M.: Selecting and implementing a computer aided scheduling system for
a large bus company, in: Voss, S., and Daduna, J. R., (eds.), Computer-Aided
Scheduling of Public Transport, Springer-Verlag, Berlin, 2001, 2003.
18. Mesquita, M. and Paixao, J. : Multiple Depot Vehicle Scheduling Problem: A New
Heuristic Based on Quasi-Assignment Algorithms. In: M. Desrochers and J.-M.
Rousseau (eds.), Computer-Aided Transit Scheduling, Lecture Notes in Economics
and Mathematical Systems 386, Springer-Verlag, Berlin, 167–180., 1992.
19. Moz, M., Respcio, A., and Vaz Pato, M: Bi-objective Evolutionary Heuristics for
Bus Drivers Rostering, Working paper 1-2007, Centro de Investigaao Operacional,
Universidade de Lisboa, 2007.
20. Pepin, A.-S., Desaulniers, G., Hertz A., Huisman, D.: Comparison of Heuris-
tic Approaches for the Multiple Depot Vehicle Scheduling Problem, Journal of
Scheduling, 10.1007/s10951-008-0072-x, 2008.
21. Ribeiro, C.C., & Soumis, F. : A Column Generation Approach to the Multiple-
Depot Vehicle Scheduling Problem. Operations Research, 42, 41–52, 1994.
22. Wang, H., Shen, J.: Heuristic approaches for solving transit vehicle scheduling
problem with route and fueling time constraints, Applied Mathematics and Com-
putation 190, 1237–1249, 2007.
23. Weider, S.: Integration of Vehicle and Duty Scheduling in Public Transport, Ph.D.
thesis, Technical University of Berlin, Germany, 2007.
24. Wren, A., Fores, S., Kwan, A.S.K., Kwan, R.S.K., Parker, M.E., and Proll, L.: A
flexible system for scheduling drivers, Journal of Scheduling, 6, 437, 2003.
25. Yunes, T., Moura, A., and de Souza, C.: Hybrid Column Generation Approaches
for Solving Real World Crew Management Problems, In Proceedings of the 27th
Conferencia Latinoamericana de Informatica, 2001.