Experimental Evaluation of Real-Time Information Services in Transit Systems from the Perspective of Users

1
Experimental Evaluation of Real-Time Information
Services in Transit Systems from the Perspective
of Users

• Antonio Mauttone
• Operations Research Department, Universidad de la
  República, Uruguay
• Ricardo Giesen
• Department of Transport Engineering and
  Logistics, Pontificia Universidad Católica de
  Chile, Chile
• Matías Estrada, Emilio Nacelle, Leandro Segura
• Undergraduate Program in Computer Engineering,
  Universidad de la República, Uruguay
• CASPT 2015, Rotterdam, The Netherlands, 19-23
  July 2015

2
Contents

• Introduction, motivation and goals
• Proposed model
• Simulation experiments
• Conclusions and future work

3
Introduction, motivation and goals
4
Introduction and motivation

• Advances on ICT.
• Real time information (RTI) services for transit
  users.
• Updated arrival time of buses to stops, available
  through internet, mobile devices and screens at
  the stops.
• Large investments.
• Influence over the performance of the system.

5
Existing models and studies

• Evaluations based in observed data Brakewood et
  al., 2014 Watkins et al., 2011.
• Analytical models Hickman and Wilson, 1995
  Gentile et al., 2005 Chen and Nie, 2015.
• Simulation models Coppola and Rosati, 2010 Cats
  et al., 2011.
• General characteristics and conclusions
• Methodologies transit assignment, random
  utility, discrete event simulation.
• Improvements measured in terms of travel time.
• Results highly depends on the particular
  hypothesis.
• Statistical significance, even across different
  cases.
• Sophisticated models are computationally costly.

6
Research goals

• Evaluate the impact of RTI over transit systems
  from the perspective of users.
• Based on detailed modeling of interactions
  between passengers and buses.
• Focused on travel time, at both aggregated and
  non-aggregated levels.
• Scenario of small city, low frequency, high
  regularity.
• Different levels of information availability.

7
Proposed model
8
Model components

• Transit system representation.
• Passenger behavior model.
• Discrete event simulation.

9
Transit system representation
Destination centroid
Origin centroid
Street node
Bus stop

• Demand model
• Each passenger is generated randomly at origin
  centroids, using a negative exponential
  distribution with mean value taken from an
  OD-matrix.
• Service model (lines)
• Sequence of network links. The bus travel time is
  truncated normally distributed with mean taken
  from the arc attribute.
• Forward and backward directions and circular
  lines.
• Frequency and timetable.

10
Passenger behavior

• Critical aspect of the model direct influence on
  performance measures (travel time).
• Dynamic characteristic given by RTI availability.
• Passengers plan their trips in terms of single
  paths, using timetable information.
• Schedule-based approach detailed modeling of
  each passenger and each bus run.
• Network representation line-database.
• Passengers maximize utility shortest paths.

11
Proposed passenger behavior models

• All-or-nothing assignment with dynamic
  rescheduling no transfers.
• Six model variants (scenarios)
• RTI-always Real time information available
  during the whole trip.
• RTI_at_origin Real time information available only
  at the origin centroid.
• RTI-1Line Real time information of a single line
  during the whole trip.
• STT Static timetable only no RTI available.
• RTI_at_stops Real time information available only
  at the bus stop.
• FBA Frequency based, no timetables nor real time
  information.
• Particular characteristics
• Models 1 to 4 schedule departure from origin.
• Models 2 and 4 do not change the line selected at
  origin.
• Models 3, 5 and 6 use the frequency to estimate
  waiting time.
• Model 6 takes the first line that leads to
  destination.

12
Discrete event simulation model

• Bus
• Created at the initial node, moves according to
  the timetable and disposed at the final node.
• We do not simulate fleet management and control.
• Passengers
• Generated according to a given OD-matrix.
• Plan the trip at the origin centroid and may
  change the selected line at the bus stop (in some
  variants).
• RTI is broadcasted immediately to passengers.
• Model implemented in C and EOSimulator library.

13
Simulation experiments
14
Methodology and goals

• Case study city of Rivera, Uruguay, 65,000
  inhabitants.
• Transit system 13 lines, low frequency (1/20 to
  1/60) and high regularity.
• Model 84 zone centroids, 378 OD-pairs, averaged
  demand over 12 hours. Size about 500 nodes and
  1500 arcs.
• Execution time simulation of 6 hours of the real
  system takes 18 seconds in a Core i7 computer.

15
Methodology and goals

• Evaluation of the transit systems performance,
  comparison among the six models.
• Aggregated measure total travel time, averaged
  over all passengers.
• Non-aggregated measures time by travel component
  and by OD-pair.
• Several independent executions.
• Sensitivity analysis
• Higher frequencies.
• Higher irregularity.

16
Current system aggregated values
Model Mean travel time (secs.)
1. RTI-always 2589
2. RTI_at_origin 2612
3. RTI-1Line 2625
4. STT 2693
5. RTI_at_stops 2960
6. FBA 3778

• Reasonable values for an average trip in the case
  study 43 - 63 minutes.
• RTI usage improves total travel time.
• RTI-always, RTI_at_origin and RTI-1Line exhibit
  similar results.
• STT is a bit higher.
• RTI_at_stops is higher because users do not schedule
  departure.
• FBA is significantly higher.

17
Non-aggregated values by travel component
1. RTI-always 2. RTI_at_origin 3. RTI-1Line 4.
STT 5. RTI_at_stops 6. FBA

• RTI-always, RTI_at_origin and RTI-1line exhibit
  similar results, even by travel component.
• Main differences are in waiting time
• RTI_at_stops seems to be not very useful.
• FBA is significantly higher (due to on-board
  travel time).

18
Non-aggregated values by OD-pair
1. RTI-always 2. RTI_at_origin 3. RTI-1Line 4.
STT 5. RTI_at_stops 6. FBA

• Different characteristics geographic distance
  between OD and service availability (lines,
  frequencies).
• Closest and farthest pairs three randomly
  selected pairs.
• The tendency already observed also holds for
  different OD-pairs.

19
Non-aggregated values waiting time
1. RTI-always 4. STT 6. FBA

• Why waiting time? Main differences among the
  different models, the most onerous component.
• Extreme models (RTI-always and FBA) and
  intermediate model (STT).
• Passengers using static timetables experience
  similar waiting time with respect to those who
  use RTI always.
• Valid for low frequencies and high regularity.

20
Sensitivity analysis higher frequencies
1. RTI-always 2. RTI_at_origin 3. RTI-1Line 4.
STT 5. RTI_at_stops 6. FBA

• Headways 20 to 60 minutes -gt 5 to 15 minutes
• Differences among models 1 to 4 are very small.
• RTI influence is less useful, when compared to
  static timetables.

21
Sensitivity analysis higher irregularity

• Model higher standard deviation in the parameter
  of the bus travel time over the network links.

Model Mean travel time (secs.) increase w.r.t. current system
1. RTI-always 2972 15
2. RTI_at_origin 3037 16
3. RTI-1Line 2979 13
4. STT 3159 17
5. RTI_at_stops 3219 9
6. FBA 4189 11

• Mean travel time increased 14 in average, w.r.t.
  current system mainly due to waiting time.
• Models where decisions are not updated using RTI
  (RTI_at_origin and STT) present the highest increase
  w.r.t. the current system.

22
Conclusions and future work
23
Conclusions

• Simple model with six variants concerning
  passenger behavior.
• Small cities, low frequencies, high regularity.
• Improvements w.r.t. worst model (FBA), in terms
  of
• Total travel time 29 using static timetables
  and 31 using RTI.
• Waiting time 37 using static timetables and 48
  using RTI.
• Using STT is a reasonable and cheap alternative,
  even for a scenario of higher frequencies.
• RTI turns itself more relevant for a scenario of
  high irregularity.

24
Future work

• Study additional cases, including
• Bigger cities.
• Less regular services.
• More complex travel patterns.
• Include other atributes on route selection
• Transfers.
• Crowdiness, etc.
• Implement a visualization tool.

25
Thanks for your attention!