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.

While automatic vehicle location, automatic passenger counting, and farebox systems began as the single-purpose systems their names imply, their value as data collection sys- tems soon became apparent. Using the expanded definition of AVL as an automatic data collection system that includes location measurement, this section describes other devices that can be integrated into the data collection system. 3.1 Automatic Passenger Counters Unlike AVL, APCs have always been designed with archived data in mind. Valuable reviews of the history of APCs are found in reports by Levy and Lawrence (17), Boyle (14), and Friedman (18). APCs use a variety of technologies for count- ing passengers, including pressure-sensitive mats, horizontal beams, and overhead infrared sensing. Automatic passenger counting has not yet seen widespread adoption primarily because of its cost and the maintenance burden it adds. Where adopted, APCs are typically installed on 10% to 15% of the fleet. Equipped buses are rotated around the system to provide data on every route. However, technological advances may soon make APCs far more common. The term “APC” can refer to a full data collection system or to simply the passenger counter as a device within a larger data collection system. Historically, APCs were implemented as full, independent systems that included location measure- ment and stop matching. In spite of the emphasis their name gives to passenger use data, they not only counted passengers but also provided valuable operation data that supported analysis of running time and schedule adherence; in effect, they doubled as (non-real-time) AVL systems. Canadian tran- sit agencies have been particularly active in exploiting APC data. OC Transpo, the Toronto Transit Commission,Winnipeg Transit, Tri-Met, and King County Metro are among the agen- cies that have long benefited from routine reports on passen- ger loads, running time distribution, and on-time performance from APC systems. Since the mid-1990s, the trend has been for APCs to become simply a component in a larger data collection system that includes automatic vehicle location. Location and stop match- ing is the duty of the vehicle location system, which operates out of a main on-board computer called the “vehicle logic unit.”The passenger counter includes sensors and a dedicated on-board computer called an APC analyzer that converts sensor information into passenger counts. Each time the bus leaves a stop, the APC analyzer closes out a record and trans- mits its on-off counts to the vehicle logic unit. From there, the data is treated like data from any other device in the data col- lection system—either stored on board for later upload, or transmitted by radio in a stop event message. By integrating APCs into an AVL system, the marginal cost of passenger counting drops dramatically. Tri-Met, already committed to fleetwide AVL and using one of the simpler APC designs, finds the marginal cost of adding passenger counting to be in the range of $1,000 to $3,000, versus unit costs of $5,000 to $10,000 often cited for stand-alone systems. This marginal cost is low enough that Tri-Met includes APCs in all new coach purchases. With 65% of its fleet already equipped, it is the only large transit system with APC penetration beyond a small sample of the fleet. Benefits of a large APC sample are discussed in Section 10.4. APC counting accuracy depends on the technology used, the care used in mounting and maintaining sensors, and algo- rithms used to convert sensor data into counts. The accuracy of finished counts also depends on the effectiveness of stop matching and identifying the end of the line, subjects discussed earlier; it also depends on algorithms used for screening, pars- ing, and balancing, which are covered in Chapter 8. 3.2 Odometer (Transmission Sensors) As mentioned earlier, all buses have electronic transmis- sion sensors that serve as odometers, giving a pulse for every axle rotation. Integrating the transmission into an automatic C H A P T E R 3 Integrating Other Devices 21

data collection system provides the basis for dead reckoning and enables data on speed to be captured. Estimating speed from GPS measurements is not reliable (except over substan- tial distances) because of random measurement errors. There- fore, odometer input is preferred to determine when a bus’s wheels start rolling after serving a stop. Some AVL systems also integrate a gyroscope, which indi- cates changes in heading. Gyroscope readings will support off- route dead reckoning and can aid in matching because they detect turns. 3.3 Door Switch APC systems in North America always include door switches to help determine when a bus is making a stop. Even when a system does not include passenger counting, door switches can be a valuable means of location matching. If a system repeatedly shows doors opening at a location not coded in the base map as a stop, that information can be used to update the base map. In some Dutch transit systems, door sensors are used to distinguish time spent holding (bus is resting at a stop, ahead of schedule, doors closed) from dwell time spent serving pas- senger movements. APC vendors in Latin America know that buses there often operate with doors open, rendering door switch readings useless. 3.4 Fare Collection Devices The traditional electronic farebox has limited data storage capacity, creating one record per one-way trip with simply a count of the trip’s boardings and revenue. Farebox manufac- turers have historically been reluctant to allow their machines to communicate with other on-board devices, citing the need to prevent fraud by keeping revenue-related information secure. Limited integration schemes, such as sharing a common oper- ator log-in and interface to the destination sign (to indicate change in route/direction), have been applied at a few transit agencies. Recent products advertise J1708 compatibility (see Section 3.6). A new development is the transactional farebox, which produces a time-stamped record for each transaction. If the fareboxes are networked to a smart bus system, transaction data can be transmitted along the data bus and collected as part of the AVL event stream. If fareboxes are not integrated, off-line integration of the farebox’s own data stream with archived AVL data, in princi- ple, should be possible, with matching performed on the basis of vehicle ID and time.A research project for the CTA attempt- ing to prove this concept found several obstacles to integrating the data sources. Farebox and AVL clocks were not synchro- nized. Also, the fare transaction data contained many unex- plained anomalies. For example, one would expect that people transferring from one route to another (the farebox transaction data includes route transferred from) would board the second bus where the two routes intersect, providing a means of ver- ifying a stop matching; however, the data shows such trans- fers occurring at multiple stops, some a good distance from the transfer point. Because farebox data is not usually analyzed at this level of detail, its quality in many respects has not mat- tered before. Improving the quality of farebox data will be a challenge to efforts to integrate it with AVL-APC data. Once this challenge is met, however, it offers the prospect of a rich data source from 100% of the fleet. While fareboxes cannot directly measure load because they do not register passengers both boarding and alighting, there are methods of estimating load based on the historical sym- metry between the boardings pattern in one direction and the alightings pattern in the opposite direction (19). As contact- less smart cards penetrate the market, card readers, some day, may be able to count passengers alighting as well as boarding. Transaction data in which the fare medium is electronic offers the possibility of tracking linked trips and analyzing transfers, by linking records with a common user ID. Know- ing the pattern of where and when a particular farecard was used to enter the system allows estimation of the cardholder’s trip pattern to be made, based on round trip symmetry. The viability of this approach has been demonstrated in the New York subway system (20) and in the multimodal Helsinki tran- sit system (21). A research project is currently under way, with promising results, using Dublin bus data in which farecard transactions are all station stamped. In the near future, Metro Transit plans to introduce smart cards, bypassing the farebox, with smart card readers inte- grated into its vehicle location system. This arrangement may finally produce the long hoped-for benefits of integrating fare collection with vehicle location. 3.5 Other Devices 3.5.1 Radio Control Head As discussed in Section 2.2.1, integrating the control head ensures that the AVL data stream gets both sign-in data and data messages sent by the bus operator to the control center. 3.5.2 Passenger Information Systems Passenger information devices, including the destination sign and next stop announcements, can be integrated with a location system; however, because they become consumers, not suppliers, of information, they add nothing directly to a data archive. Their integration does bring an indirect benefit to archived data by increasing the pressure for the system to match routes and stops accurately. 22

3.5.3 Wheelchair Lift Lift sensors can initiate a location-stamped record of lift use, a valuable piece of information for off-line analysis of both ridership and running time. In the survey, no examples of lift sensors being used in AVL systems were found; lift data, where available, came from operator-initiated messages sent by radio. 3.5.4 Silent Alarm AVL systems usually include an operator-initiated silent alarm for emergencies. Its recording is valuable for incident investigations. 3.5.5 Mechanical Sensors Transit buses have had electronic controls and monitor- ing systems for many years (22). Besides transmission sen- sors, such systems include, for example, engine heat and oil pressure sensors. AVL systems have sometimes taken input from such sensors, triggering mechanical alarms for high tem- perature or low pressure; however, false positives have been too frequent and therefore no use has been found for mechan- ical alarms. It has been suggested that mechanical data incorporated into a data archive (as opposed to triggering real-time alarms) may yield valuable insight into maintenance needs. 3.6 Integration and Standards On-board devices can be integrated in an ad hoc fashion, or following a systematic integration standard. Standardization helps promote the cost and efficiency benefits of modularity and re-use. 3.6.1 SAE Standards and Smart Bus Design Systematic on-vehicle integration of devices has been called the “smart bus” concept. The principal on-vehicle device is the main data collection computer or vehicle logic unit. In principle, the vehicle logic unit and other devices are each connected to a twisted pair of copper wire running the length of the vehicle and called the “data bus.” (In practice, there are often a few devices, such as GPS receivers, connected directly to the vehicle logic unit instead of via the data bus. Wireless networking has also become possible as a substitute for a phys- ical data bus.) The network consisting of the data bus and attached devices is a local area network (LAN, often called a “vehicle area network” (VAN). Devices broadcast messages on the network when triggered by an event; other devices receive or ignore the message, depending on how they are programmed. A communication protocol governs message types and man- ages traffic on the VAN. Nearly all the relevant devices man- ufactured today comply with the J1708 family of standards (23, 24) published by SAE, the integration standard used in many AVL systems. Some AVL integrators use a proprietary VAN protocol that they claim handles message traffic better. An advantage of integration is providing operators with a single interface and a single sign-in, which can be shared (in principle) with such disparate devices as the radio, the event recorder (a function usually taken by the vehicle logic unit), the farebox, the stop announcer, and the destination sign. In practice, fareboxes are rarely integrated and therefore have a separate interface. The most significant integration is the integration of APC with AVL, first implemented in the mid-1990s at Tri-Met. The AVL vendor provided a smart bus with location tracking; therefore, the APC subcontractor had to provide only the pas- senger sensors and APC analyzer, relying on the AVL system for stop matching. Another example is a stop announcement system vendor who provides the smart bus system, with APCs added as a supplemental device. While it may seem obvious that AVL, APC, and stop announcement systems should share location systems and on-board computers, their integration is only a recent devel- opment. In fact, for various cost and contract reasons, sepa- rate location systems are still being installed independently at some transit agencies that lack the smart bus foundation, with buses having multiple GPS receivers, multiple on-board com- puters, and, in spite of efforts to avoid it, multiple operator interfaces. Using an open, standards-based smart bus design when procuring an AVL, APC, stop announcement, or event recording system substantially lowers the marginal cost of adding the other functions and provides flexibility for later procurements. 3.6.2 Other Integration and Standards Efforts Transit Communications Interface Profiles (TCIP) The TCIP project, started in 1996, is a standards develop- ment effort sponsored by the U.S.DOT’s Joint Program Office for Intelligent Transportation Systems (ITS). Its mission has been to define the data elements and message sets that can be specified as an open data interface for transit data interchange activities. Phase 1, completed in 1999, established a transit ITS data interface “Framework” and eight “Business Area Object Standards.”Phase 2, completed in June 2001, built on the work of Phase 1 by developing the transaction sets, application pro- files, and guidebooks required to test and implement TCIP. Some of the pertinent TCIP developments include • The definition of automatic vehicle location objects, includ- ing compass bearing parameter, current time, current date, 23

trip distance, position, velocity vector, total vehicle distance, and milepost identification; • The definition of conformance groups that consist of a list of objects required to support a specific function. Confor- mance groups were defined for dead reckoning, triangula- tion, GPS, etc.; • The development of a standard on spatial representation objects, including a data dictionary and the definition of message objects set; and • The development of a standard for on-board objects, also including a data dictionary and the definition of message objects set. TCIP object definitions include most schedule features, which are important for matching a vehicle and data collected on it to the route and trip on which it is operating. Some AVL and APC vendors have adopted the TCIP standard for their schedule data. However, TCIP has not yet been widely adopted by transit agencies as part of their product specifications and Requests for Proposals. Moreover, there are aspects of sched- ules that are not covered in TCIP, such as when a bus is simul- taneously discharging passengers from an inbound trip and picking up passengers for an outbound trip. Among the peo- ple working to improve the TCIP standard are those involved with AVL and APC data. Location Referencing Guidebook The recently published Best Practices for Using Geographic Data in Transit: A Location Referencing Guidebook (12), funded jointly by FTA and the Transit Standards Consortium, pro- motes effective practices in the exchange and use of spatial data, including stop and route definitions. FTA National Transit GIS Initiative The FTA initiated in the mid-1990s a National Transit Geo- graphic Information System to develop an inventory of pub- lic transit assets in the United States. Although the effort focused primarily at a high national level, it was also designed to encourage more use of GIS tools by transit systems. Its 1996 report discusses the design of bus stop and route data- bases as well as specifications for data exchange involving GIS databases (25). This effort was to some extent a precur- sor to the Location Referencing Guidebook project discussed earlier. 24