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.

8AVL and APC systems are capable of gathering an enormous quantity and variety of operational, spatial, and temporal data that—if captured, archived, and analyzed properly—hold sub- stantial promise for improving transit performance by sup- porting improved management practices in areas such as service planning, scheduling, and service quality monitoring. Historically, however, such data has not been used to its full potential. Many AVL systems, designed primarily for real-time applications, fail to capture and/or archive data items that would be valuable for off-line analysis. Recent technological advances have created new opportunities for improving the quantity, variety, and quality of captured and archived data and for analyzing it in meaningful ways. The objective of this research was to develop guidance for the effective collection, archiving, and use of AVL-APC data to improve the perform- ance and management of transit systems. Automatically collected data can play two important roles in a transit agency’s service quality improvement process. As illustrated in Figure 1, there are two quality improvement cycles: one in real time and one off line. In the real-time loop, automatically collected data drives operational control, aid- ing the transit agency in detecting and responding to devia- tions from the operational plan; it is also a source of real-time information that can be conveyed to customers using a vari- ety of media. In the off-line loop, automatically collected data that has been archived drives analyses that aid the transit agency in evaluating and improving its operational plan. Ulti- mately, good operational performance and high passenger satisfaction follow from having both a good operational plan and good operational control. 1.1 Historical Background Historically, AVL system design has emphasized the real- time loop, giving little or no attention to the off-line loop. Many AVL systems do not archive data in a manner useful for off-line analysis because they were not designed to do so. The inability of AVL to deliver data for off-line planning analy- sis was a major theme of a 1988 conference sponsored by the Canadian Urban Transit Association [see, for example, Furth (1)]. Through the mid-1990s, this situation continued. A report summarizing data analysis practice in 1998 found that, of the seven U.S. transit agencies surveyed that had AVL systems, all relied entirely on manual data collection for run- ning time analysis, and only three used AVL data to monitor schedule adherence (2). Broward County Transit illustrates how AVL systems are not commonly oriented toward archiving data (3). Its AVL system archived incident messages, but not routine poll data, which gave vehicle location approximately every 60 s. Because incident messages occur only on an exception basis, they can- not support most running time and schedule adherence analyses. Although the poll messages were written to an Ora- cle database as a utility for system maintainers, it was over- written every 2 min because no permanent use for that data was foreseen. To archive the poll data, an analyst wrote a pro- gram that copies the contents of the Oracle database to a per- manent database every 2 min. This archive enabled him to plot trajectories and review particular trips. Because real-time data needs differ from those of off-line analysis, simply warehousing AVL records does not in itself guarantee a useful data archive. The single greatest problem with traditional AVL data is that it consists mostly of poll records, in which a vehicle reports its location when polled by a central computer in round-robin fashion, every 60 seconds or so. Poll data can be characterized as “location-at-time” data, as distinct from “time-at-location” data such as reporting when a bus arrives at a stop. Either one is adequate for tracking a bus’s location in real time, but most off-line analyses (e.g., running time, headway, or schedule adherence) need records of when buses arrive or depart from stops and timepoints. There are other important differences between real-time and archived data needs. Some AVL systems transmit data only when a bus’s schedule deviation is outside a “normal” range C H A P T E R 1 Introduction

(e.g., 0 to 3 min late). For real-time control, or even passenger information, exception data like this may be adequate; how- ever, a data stream containing only exception data is entirely unsuitable for analyzing running time. Another difference is that real-time data is more tolerant of errors. If faults in either the location system or the base map make a bus’s apparent track momentarily jump a few miles off route, service controllers learn quickly how to ignore such anomalies; however, in a data archive, such errors may go undetected and distort running time or schedule deviation analyses. APC systems, unlike AVL, have always been oriented toward off-line analysis. Historically, APC systems were inde- pendent of (real-time) AVL systems. Their adoption has been far more limited than AVL systems. The weaker market for APCs has resulted in several vendors having gone out of busi- ness and has limited the amount of vendor-developed soft- ware for data analysis. (That trend, fortunately, is being reversed as technology advances.) Transit agencies have been largely left on their own to develop their APC systems; pio- neering successes include transit systems in Seattle, Ottawa, Winnipeg, and Toronto. A radical shift in AVL system development in favor of archived data collection occurred in the mid-1990s, when Tri- Met, together with an AVL vendor, designed a hybrid AVL-APC system featuring on-board event recording and radio-based communication. Records for every stop and other events are created in the on-board computer, while messages useful for real-time monitoring (e.g., bus is late or off-route) are radioed in. Another innovation was that APCs, installed on a sample of the fleet, do not have their own location system; they simply count passengers and rely on the AVL system to provide the location stamp.This design lowered the marginal cost of instru- menting buses with APCs to the point that all new buses at Tri- Met now have APCs. With 65% of the fleet equipped, Tri-Met stands out as the only agency with more than 20% of its fleet APC-equipped. After a few years’ break-in period, Tri-Met enjoys a comprehensive archive of high-quality location data, making it a leader in archived AVL-APC data analysis. NJ Transit took a still more radical step in designing, in con- junction with an AVL vendor, an AVL-APC system that, for the time being at least, does not include real-time radio communi- cation. Although they envision integrating radio in the future, the current configuration is strictly for off-line analysis. In the Netherlands, AVL systems with on-board data recording were installed in some cities in the early 1990s. However, the lack of analysis tools and poor quality of base maps led to their data being largely unused until about 1996, when the Delft University of Technology teamed up with the municipality of Eindhoven and its transit operator, Hermes, to improve their data quality and develop and apply analysis tools. Those tools, originally developed around 1980 for use with manually collected data, were coded into the software package TriTAPT (Trip Time Analysis in Public Transport), which has also been applied at transit agencies of the Hague, Rotterdam, and Utrecht. A significant recent development for archived AVL-APC data is the growing demand for stop announcement systems, which require considerable on-board computing power to match stops in real time. The creators of those systems found it easy to simply add data recording, creating a new function for their product and thus creating a new source of archived AVL data—one that promises to be very accurate by virtue of being designed for a rather demanding application. In the system installed in the Chicago Transit Authority (CTA), APCs have also been integrated on a sample of the fleet. The movement to integrate systems and on-board devices is serving to blur the distinction between what first appeared as stand-alone systems. In recent years, for example, some cities, including Minneapolis, have integrated APCs into real-time AVL systems, with stop data transmitted over the air to a central computer for archiving. APC and event record- ing has been added to stop announcement systems, and stop announcements have been added to real-time AVL systems. However, regardless of what functions a data collection system may have, there are common needs for archived data analysis. Therefore, this report will sometimes use the term AVL in a generic sense, meaning any automatic data collection system that includes location data. 1.2 Research Objective Technological advances erase all question of the feasibility of collecting and archiving high-quality location data. Two primary issues remain: • How should automatic data collection systems and their associated databases and software be designed so that they capture and facilitate the analysis of AVL-APC data? 9 Service Plan Transit Operation Automated Data Gathering Operational control & Passenger info Archive Data Analyze Performance and Demand Real time loop Off-line loop Figure 1. Service quality improvement cycles.

• What new analysis tools might become possible using this kind of archived data? 1.3 Research Approach The research followed three major thrusts, described in this section: • Survey of industry practice • Analysis of data systems and opportunities • Development of analysis tools 1.3.1 Survey of Practice: Breadth and Depth Six information sources were used to review (1) AVL, APC, and related systems with respect to their ability to capture and archive operational data and (2) industry practice in using such archived data. Together, these sources provide both a broad view of historical and current practice and an in-depth view of practice at transit agencies in the United States, Canada, and Europe. The first source was the literature on intelligent systems in transit and on transit analysis tools. A helpful starting point was a pair of state-of-practice reviews done for the U.S.DOT’s Volpe Center (4, 5). A second source was a mail survey of U.S. transit agencies concerning their use of AVL and APC systems conducted in Spring 2001 by Robbie Bain. A third source was a wide telephone survey of APC and AVL users. From the first two sources, the researchers assembled a preliminary list of some 122 U.S., 14 Canadian, and 26 Euro- pean transit agencies using or planning to use AVL or APC sys- tems. From that list, staff members were telephoned at transit agencies reputed to be advanced in their use of AVL or APC data. Telephone interviews were successfully conducted with the 20 U.S. and 14 Canadian transit agencies listed in Table 1. The fourth source was in-depth case studies at nine transit agencies in the United States, Canada, and the Netherlands, listed in Table 2. Appendixes A through I of TCRP Web Doc- ument 23 (available from the TRB website: www.trb.org) con- tain the case study reports. In addition, a partial case study was conducted of Uestra, the transit agency in Hannover, Germany. The nine case study agencies provide a broad range in many respects. They represent the United States, Canada, and Europe. Within the United States, they span the East Coast, Midwest, and West Coast and include agencies whose oper- ations are statewide, metropolitan, and limited primarily to a central city. Some have focused on AVL; others on APCs; others on event recorders; and some on two or more of these functions. They represent a range of vendors, system design, and system age. Some of the selected agencies have well-established practice with archived data, with impacts throughout the organization; others are still in the devel- opment stage. These agencies have had failures as well as successes, and lessons are learned from both. A brief description of the AVL-APC systems at the case study sites will provide some helpful background. 10 State/ Province City / Area Agency CA San Jose Valley Transportation Authority CO Denver Regional Transportation District FL Broward County Broward County Transit FL Orlando LYNX IA Des Moines Metropolitan Transit Authority IA Sioux City Sioux City Transit IL Chicago CTA IL Chicago suburbs Pace MA Cape Cod Cape Code Regional Transit Authority MD Baltimore / state Maryland Transit Administration MI Ann Arbor Ann Arbor Transportation Authority MN Minneapolis Metro Transit MO Kansas City Kansas City Area Transportation Authority NJ New Jersey (statewide) NJ Transit NY Buffalo Niagara Frontier Transportation Authority OR Portland Tri-Met TX Dallas Dallas Area Rapid Transit TX San Antonio VIA WA Seattle King County Metro WI Milwaukee Milwaukee County Transit AB Calgary Calgary Transit AB Edmonton Edmonton Transit BC Vancouver TransLink BC Victoria BC Transit MB Winnipeg Winnipeg Transit NS Halifax Halifax Metro Transit ON Hamilton Hamilton Street Railway ON London London Transport Commission ON Ottawa OC Transpo ON Toronto Toronto Transit Commission QC Hull Société de transport de l’Outaouais QC Montreal STM QC Montreal South Shore Société de Transport de la Rive Sud de Montreal QC Quebec Société de transport de la Communauté urbaine de Quebec Table 1. Agencies interviewed in wide telephone survey.

• Tri-Met’s system features on-board computers on all of their buses, connected by radio to provide real-time AVL, and stores on-board records for every stop as well as other events. APCs are on about 65% of the fleet. Stop records include on and off counts (void for buses without APCs), stop ID, longitude, latitude, door open moment, dwell (i.e., door open) duration, moment of exiting a 30-m radius zone around the stop, indicators of door opening and lift use, and maximum speed since the previous stop. Location and status are radioed to the control center on an exception basis (e.g., when more than a predetermined deviation from schedule occurs or when the bus is off route). Operator- initiated coded radio messages (e.g.,“road blocked by train” or “pass-up”) are recorded in the on-board computer with time and location stamp as well as transmitted in real time. The on-board computer is also connected to a traffic signal priority request emitter, triggered only when the bus is behind schedule. • The HTM (the Hague) system is like Tri-Met’s, featuring on-board event recording at every stop, APCs on a frac- tion of the fleet (in this case, about 25%), radio transmis- sion of real-time location to central control, and traffic signal priority request emitters. • Eindhoven’s Hermes system is an event recorder, not con- nected to the radio. Location is based on sub-pavement bea- cons at each signalized intersection and odometer. Stop records include door opening and closing time. Records are also made of each time the bus passes a 5 km/h speed threshold, used to determine how much time is spent stopped or at crawl speed at different points on the route. • A stop announcement system currently being installed at the CTA stores stop records on board all buses. On buses with APCs (15% of the fleet), stop records include on and off counts. At the same time, an independent 1995-vintage AVL system polls buses for their location every 40 to 70 s. Although the poll messages are recorded, they are not matched to location and are therefore unsuitable for routine operations analysis. • At NJ Transit, an AVL vendor supplied the on-board com- puter with location tracking function, even though NJ Transit’s system is not connected to a radio, and integrated it with APCs. Only a fraction of the fleet is instrumented; that fraction has been concentrated on one route to make operations analysis of that route possible. It features exten- sive and frequent event recording, including stop records, and was designed to enable later integration with the radio and other devices through a J1708 network. • At Metro Transit, the AVL vendor supplied the on-board computer, which is connected to the radio and, on 12% of the fleet, to APCs. The radio carries both round-robin poll data (bus location when polled) for real-time monitoring and event messages. Off-line analysis will ignore the poll data except for incident investigations, and instead use event messages, including timepoint messages. Stop messages, including passenger counts, are not recorded on board, but are transmitted by radio whenever an APC-instrumented bus actually serves a stop. During periods of radio failure, event messages are recorded on board, uploaded at the end of the day, and inserted into the radio message database. • King County Metro has both AVL and APC systems that share signpost, odometer, clock, and operator login (route/ run) information, but are otherwise independent. The AVL system sends timepoint messages as well as performs round- robin polling. Service analysts at King County Metro had long relied on APC records for operations analysis; however, because of improvements in timepoint detection made around 2000, AVL timepoint data is now the preferred data source, because AVL data is implemented fleetwide, offer- ing large and recent data samples. • OC Transpo and Societé de Transport de Montréal (STM) have stand-alone APCs. OC Transpo is a long-time APC user and has used its APC system extensively for opera- tions analysis as well as passenger count analysis. STM has recent in-depth experience in testing and approving new APC systems. The fifth source of information was a 1-day workshop for vendors held on May 28, 2002. An open invitation was extended to vendors of AVL, APC, and related products, with specific invitations sent to known vendors. They were joined by panel members, representatives of several of the case study sites, and members of the project team, providing a good rep- resentation of interested transit agency staff and independent researchers. Participants other than project team members are listed in Table 3. The researchers also benefited from direct interaction with vendors referred by transit agency staff from the case study sites. Finally, the researchers used their knowledge of the transit industry and related industries, supplemented by informa- tion received from members of the project panel. 11 Location Agency Appendix Portland, OR Tri-Met A New Jersey (statewide) NJ Transit B Seattle, WA King County Metro C Chicago, IL CTA D Montreal, QC STM E Ottawa, ON OC Transpo F Eindhoven, the Netherlands Hermes G The Hague, the Netherlands HTM H Minneapolis, MN Metro Transit I Table 2. Case study sites.

1.3.2 Analysis of Data Systems and Opportunities The second thrust of the research was identifying actual and potential ways that archived AVL-APC data could be used and analyzing these identified ways in terms of needs for data cap- ture, accuracy and sample size, data structures, and analysis methods. At the same time, data collection and database sys- tem designs were analyzed in terms of their capability for sat- isfying those needs. Based on that comparison, the researchers developed guidance regarding system design. Another part of this thrust was the development, as a proof of concept, of one innovative data structure for analyzing serv- ice on a trunk shared by multiple patterns or lines. 1.3.3 Development and Demonstration of Improved Tools If there is no good archived data, there appears to be no need to develop tools to analyze it. And if there are no useful tools to apply, there appears to be no need to purchase a sys- tem to gather the data. Because of this chicken-and-egg rela- tionship between analysis tools and the practice of capturing and archiving data, the third main thrust of this project was to develop and demonstrate the use of improved analysis tools that take advantage of archived AVL-APC data. This thrust, in its effort to accelerate the cycle of develop- ment, had two facets: TriTAPT and improved analysis tools. Delft University’s software package TriTAPT contains analy- sis tools related to running time and passenger counting. Under the terms of this project, this software will be available with no license fee for 4 years to transit agencies in the United States and Canada. In the course of the project, it was tested by three agencies (Tri-Met, Metro Transit, and the Massachusetts Bay Transportation Authority [MBTA]); and the feedback was used to help adapt it to U.S. practice. The second facet was the development of improved analy- sis tools. Improved tools for running time analysis were developed within TriTAPT, while prototype tools for ana- lyzing passenger waiting time and crowding were developed on a spreadsheet platform. 1.4 Report Outline This chapter describes the historical background, the research objective, the research approach, and the case study sites. Chapters 2 and 3 review systems used to collect data. Chap- ter 2 covers the core vehicle location system including on- board computer and communication. Chapter 3 covers other on-board devices that can be part of a data collection system. These chapters analyze how the design of an AVL system affects the types and quality of data that it delivers. Chapter 4 reviews actual and potential uses of archived AVL-APC data, analyzing for each use the kind of AVL-APC data it requires.With the previous two chapters, it provides the logical progression from data use to data collection system (i.e., what kind of data is needed to perform a certain type of analysis and what kind of data collection system is needed to collect that data). Chapters 5 through 7 describe specific analysis tools that were developed in the course of this project: tools for analyzing running time, passenger waiting time, and passenger crowding. Chapters 8 and 9 focus on passenger count data. Chapter 8 deals with schedule matching, trip parsing, and load bal- ancing methods and includes some newly developed pars- ing and balancing methods. Chapter 9 deals with sampling issues and, in particular, how APC data can be used to esti- mate annual systemwide passenger-miles in order to satisfy NTD requirements. Chapters 10 and 11 offer guidance on the design of auto- matic data collection systems (Chapter 10) and on the design of software used to store and analyze archived data (Chapter 11). Chapter 12 discusses organizational issues associated with AVL-APC data collection and archiving. Chapter 13 offers conclusions. Appendixes A through I, previously published as part of TCRP Web-Only Document 23, are case studies. 12 Type Participants Vendor Representatives Dirk van Dijl, ACIS Alain de Chene, Infodev Carol Yates, Orbital George Mount, NextBus Andreas Rackebrandt, INIT Neil Odle, IRIS Anil Panaghat, US Holdings Vijay Raganath, consultant with Delaware Transit Hershang Pandya, US Holdings Rohit Patel, Intelect Corporation Mike Kushner, Logic Tree Panel Members, Liaisons, and Additional Reviewers Jim Kemp, NJ Transit (panel chair) Wei-Bin Zhang, Univ. of California PATH program Fabian Cevallos, Broward County Transit Gerald Pachucki, Utah Transit Authority Tom Friedman, King County Metro Kimberly Slaughter, S.R. Beard Erin Mitchell, Metro Transit Yuko Nakanishi, Research and Consulting Sarah Clements, FTA Bob Casey, U.S.DOT Volpe Center Stephan Parker, TRB Eric Bruun, consultant Case Study Site Representatives (in addition to panel members already listed) Steve Callas, Tri-Met Kevin O’Malley, CTA Michel Thérer, STM Glenn Newman, NJ Transit Table 3. Vendor workshop participants.

Part of this project was the development of software analy- sis tools. Spreadsheet tools for analyzing passenger waiting time and crowding, described in Chapters 6 and 7, are available on the project description web page for TCRP Project H-28 on the TRB website (www.trb.org). TriTAPT, which contains a suite of analysis tools including running time analysis tools developed in this project, is available with no license fee to U.S. and Cana- dian transit operators through the end of 2009; to request a copy including documentation, sample data files, and a set of input data conversion routines, please e-mail a request to tritapt@coe.neu.edu. The conversion routines were developed for the native format of input data used by those agencies that until now have used TriTAPT; agencies may have to adapt them to their particular input file formats. Other products of this project were three papers published in Transportation Research Record: Journal of the Transportation Research Board. • “Designing Automated Vehicle Location Systems for Archived Data Analysis” (6) contains material that is sum- marized in Chapters 2, 3, 4, and 10. • “Making Automatic Passenger Counts Mainstream: Accu- racy, Balancing Algorithms, and Data Structures” (7) con- tains material that is reproduced in Chapters 8 and 9. • “Service Reliability and Hidden Waiting Time: Insights from AVL Data” (8) contains material that is covered in Chapter 6, as well as theoretical material that is not repeated in this report. 13