Using Archived AVL-APC Data to Improve Transit Performance and Management (2006)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

This chapter describes running time analysis and scheduling tools that were developed and/or improved as part of this proj- ect. They use statistical methods to create running time sched- ules, taking advantage of the large sample sizes afforded by AVL data,and are part of TriTAPT software developed by researchers at the Delft University of Technology. The primary tools described in this chapter are packaged as two integrated analy- ses: the first divides the day into running time periods and establishes route running times for each period, and the sec- ond allocates running time over a route’s segments. If the cap- tured data allows the identification of control (holding) time, these running time tools will be applied to the net running time, which excludes control time. Both analyses use graphical reports or screens, behind which are exportable tables generated from AVL data. They apply to a single route-direction, using data from any number of days. 5.1 Running Time Periods and Scheduled Running Time The first analysis, called “homogeneous periods,” is a semi- automated, interactive tool for establishing running time periods (periods of constant scheduled running time) and scheduled running times. This tool allows the user to exam- ine the feasibility of the current set of scheduled running times or a user-proposed set of running times, and it also sug- gests running times and periods automatically. 5.1.1 Feasibility of the Current Timetable Figure 8 shows an analysis of the current running times (ver- tical axis) and running time periods across the day (horizontal axis). Features include • A statistical summary of observed running time for each scheduled trip, showing mean (gray bar height), two per- centile values (jagged lines, set for this figure at 50th and 80th percentile), and maximum observed running time (arrow); • Current running time periods, bounded by heavy vertical lines, with a similar heavy horizontal line indicating current allowed time; and • Suggested allowed times (thick, gray horizontal lines), about which more will be said later. At the bottom of the rectangle for each running time period is a calculated value called feasibility; it represents the percent- age of observed trips in the running time period whose run- ning time was less than or equal to the current allowed time. 5.1.2 Suggesting New Running Times and Running Time Periods In the graph shown in Figure 9, a set of allowed times and running time periods suggested automatically by the program are shown and analyzed. A feasibility value is shown for each suggested period. Current allowed times are also visible in the background as solid horizontal line segments. The algorithm that suggests running time periods and allowed times seeks a compromise between trying to closely match the data and having periods as long as possible in order to make scheduling and control simpler. TriTAPT offers users two algorithms for selecting homogeneous periods: • For one algorithm, users set two percentile limits, for exam- ple, 50% and 80% (the values used in this section’s figures). The algorithm then seeks periods for which a whole- minute running time can be suggested that lies between the 50th-percentile and 80th-percentile observed running time for (almost) every trip in that period. • For the second algorithm, users specify a single feasibility value and a tolerance–for example, 85% and 2 min. Then, the algorithm seeks periods for which a running time can be C H A P T E R 5 Tools for Scheduling Running Time 41

42 Suggested periods based on observed net route section times (feasibility range 50% - 80%) Line: Route: 1 1 Company: From: To: Stop 1 Stop 44 TUD Departure From: Until: times 07:00 20:00 Dates: 2004/02/17 until 2004/09/10 Mon 2 Tue 2 Wed 2 Thu 2 Fri 2 Sat 0 Sun 0 Total 10 Trips scheduled: Trips used: Trips excluded: 750 568 36 ( ( 76 5 (Calc) %) %) 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 time [hh:mm] 0 15 30 45 60 75 Count ro u te s ec tio n tim e [m ] Tr ita pt 1 .0 (b 82 ) li ce ns e h old er is Pe ter K no pp ers , T ec hn isc he U niv ers ite it D elf t. C op yri gh t © 1 99 7- 20 06 T U De lft 8 7 8 7 7 8 8 8 8 7 9 8 7 7 8 6 9 7 9 9 9 5 5 7 8 7 9 9 8 9 8 6 9 7 8 8 6 8 9 8 8 8 9 8 6 6 9 8 6 7 6 8 9 9 9 9 9 8 8 7 8 6 8 8 6 6 8 7 4 8 4 8 7 9 6 31.0% 31.9%48.7% 48.9% 40.6% 47.2% 18.5% 45.5% 42.2% 44.6% Figure 8. Analysis of current running times. Figure 9. Analysis of automatically suggested running times and periods. Suggested periods based on observed net route section times (feasibility range 50% - 80%) Line: Route: 1 1 Company: From: To: Stop 1 Stop 44 TUD Departure From: Until: times 07:00 20:00 Dates: 2004/02/17 until 2004/09/10 Mon 2 Tue 2 Wed 2 Thu 2 Fri 2 Sat 0 Sun 0 Total 10 Trips scheduled: Trips used: Trips excluded: 750 568 36 ( ( 76 5 (Calc) %) %) 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 time [hh:mm] 0 15 30 45 60 75 Count ro u te s ec tio n tim e [m ] Tr ita pt 1 .0 (b 82 ) li ce ns e h old er is Pe ter K no pp ers , T ec hn isc he U niv ers ite it D elf t. C op yri gh t © 1 99 7- 20 06 T U De lft 8 7 8 7 7 8 8 8 8 7 9 8 7 7 8 6 9 7 9 9 9 5 5 7 8 7 9 9 8 9 8 6 9 7 8 8 6 8 9 8 8 8 9 8 6 6 9 8 6 7 6 8 9 9 9 9 9 8 8 7 8 6 8 8 6 6 8 7 4 8 4 8 7 9 6 58.8% 73.7% 66.6% 75.2% 65.4%65.1% 69.1% 58.4% 55.8%

suggested that lies within 2 min of the 85th-percentile observed running time for (almost) every trip in that period. These algorithms include various rules for expanding, com- bining, and splitting periods. Other running time analysis pro- grams have similar heuristic algorithms. To the researcher’s knowledge, there is no “optimal” formulation for the design of running times and running time periods. 5.1.3 “What-If” Experimentation with Period Boundaries and Allowed Times This tool allows users to modify both period boundaries and allowed times. The starting point for experimentation can be either the current schedule or the running time peri- ods and allowed times suggested by the program (based on user-selected parameters). Graphical tools allow the user to simply drag period boundaries right or left, split a period, com- bine periods, and drag proposed allowed times up or down; in response to any change, the program recalculates each period’s running time feasibility. Figure 10 shows a user-created set of running time periods and running times and the resulting feasibilities for the same dataset as the previous two figures. Having a program automatically suggest new periods and allowed times based on user-supplied parameters, while also allowing schedule makers to experiment with and propose their own set of periods and running times, gives schedule makers the power to combine design with analysis. As men- tioned earlier, the algorithms that suggest homogeneous peri- ods and running times are “compromisers,” not “optimizers.” They follow reasonable, systematic rules for determining run- ning times, but given that any solution is an imperfect com- promise, users may be able to find solutions they prefer. For example, these algorithms do not consider whether adding a minute of running time might require an extra bus, nor do they consider the burden on passengers of changing the pub- lished schedule. Schedule makers can bring this kind of knowl- edge into the design process; they therefore need the flexibility to modify suggested running times and have the program analyze what will happen. 5.2 Determining Running Time Profiles Using the Passing Moments Method Once running times for a given route (or route segment) and period of the day are selected, the next step is to divide the chosen route (or segment) time by (smaller) segments, creat- ing a scheduled running time profile (cumulative allowed time from the start of the line). This step must be performed sepa- rately for each running time period. For example, take the period 8:06 to 8:42, for which the selected allowed time in Fig- ure 10 was 64 minutes. In the graph shown in Figure 11, the suggested running time profile is shown as the heavy line with 43 Suggested periods based on observed net route section times (feasibility range 50% - 80%) Line: Route: 1 1 Company: From: To: Stop 1 Stop 44 TUD Departure From: Until: times 07:00 20:00 Dates: 2004/02/17 until 2004/09/10 Mon 2 Tue 2 Wed 2 Thu 2 Fri 2 Sat 0 Sun 0 Total 10 Trips scheduled: Trips used: Trips excluded: 750 568 36 ( ( 76 5 (Calc) %) %) 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 time [hh:mm] 0 15 30 45 60 75 Count ro u te s ec tio n tim e [m ] Tr ita pt 1 .0 (b 82 ) li ce ns e h old er is Pe ter K no pp ers , T ec hn isc he U niv ers ite it D elf t. C op yri gh t © 1 99 7- 20 06 T U De lft 8 7 8 7 7 8 8 8 8 7 9 8 7 7 8 6 9 7 9 9 9 5 5 7 8 7 9 9 8 9 8 6 9 7 8 8 6 8 9 8 8 8 9 8 6 6 9 8 6 7 6 8 9 9 9 9 9 8 8 7 8 6 8 8 6 6 8 7 4 8 4 8 7 9 6 63.2%61.3%69.6% 60.2% 66.6% 59.1% 65.4%65.1% 61.9% 64.5% Figure 10. Analysis of user-proposed running times and periods.

asterisks at each stop. To show the relation of the suggested running time profile to observed running time data, this for- mat includes a light line for every observed running time in the selected period, anchored to a start at time 0. The suggested running time profile uses Muller’s Passing Moments method, setting the running time from a timepoint to the end of the line equal to the f-percentile completion time from that timepoint, where f is the feasibility (or attainabil- ity) of the overall route time. For example, in Figure 11 the overall route time has 70% feasibility, and so running time from each timepoint to the end of the line is set equal to the 70th-percentile completion time from that timepoint. If run- ning time data is available at the stop level, a data-driven, stop-level running time profile will be created, which can be valuable for passenger information, operational control, and traffic signal priority. Running time periods and running times accepted in the homogeneous periods analysis are stored in memory and listed in a menu, so that users can choose them one at a time to cre- ate running time profiles using the Passing Moments tool. 44 Passing moments (Attainability = 69.7%, net time = 64:00) Line: Route: 1 1 Company: From: To: Stop 1 Stop 44 TUD Departure From: Until: times 08:06 08:42 Dates: 2004/02/17 until 2004/09/10 Mon 2 Tue 2 Wed 2 Thu 2 Fri 2 Sat 0 Sun 0 Total 10 Trips scheduled: Trips used: Trips excluded: 40 31 1 ( ( 78 3 (Calc) %) %) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 stop 0 15 30 45 60 Time ro u te s ec tio n tim e [m ] Tr ita pt 1 .0 (b 82 ) li ce ns e h old er is Pe ter K no pp ers , T ec hn isc he U niv ers ite it D elf t. C op yri gh t © 1 99 7- 20 06 T U De lft 00:00 01:48 03:04 04:02 05:22 06:38 07:36 08:47 09:36 10:33 11:39 13:38 14:45 15:58 18:34 19:46 20:28 22:49 24:38 25:55 26:53 28:32 29:54 31:11 32:54 33:58 34:35 35:57 38:20 39:21 40:45 41:33 42:34 43:37 44:48 46:30 47:52 49:01 50:04 51:17 52:40 54:14 57:10 64:00 Figure 11. Segment running times or Passing Moment.