National Academies Press: OpenBook

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

Chapter: Chapter 2 - Automatic Vehicle Location

« Previous: Chapter 1 - Introduction
Page 14
Suggested Citation:"Chapter 2 - Automatic Vehicle Location." National Academies of Sciences, Engineering, and Medicine. 2006. Using Archived AVL-APC Data to Improve Transit Performance and Management. Washington, DC: The National Academies Press. doi: 10.17226/13907.
×
Page 14
Page 15
Suggested Citation:"Chapter 2 - Automatic Vehicle Location." National Academies of Sciences, Engineering, and Medicine. 2006. Using Archived AVL-APC Data to Improve Transit Performance and Management. Washington, DC: The National Academies Press. doi: 10.17226/13907.
×
Page 15
Page 16
Suggested Citation:"Chapter 2 - Automatic Vehicle Location." National Academies of Sciences, Engineering, and Medicine. 2006. Using Archived AVL-APC Data to Improve Transit Performance and Management. Washington, DC: The National Academies Press. doi: 10.17226/13907.
×
Page 16
Page 17
Suggested Citation:"Chapter 2 - Automatic Vehicle Location." National Academies of Sciences, Engineering, and Medicine. 2006. Using Archived AVL-APC Data to Improve Transit Performance and Management. Washington, DC: The National Academies Press. doi: 10.17226/13907.
×
Page 17
Page 18
Suggested Citation:"Chapter 2 - Automatic Vehicle Location." National Academies of Sciences, Engineering, and Medicine. 2006. Using Archived AVL-APC Data to Improve Transit Performance and Management. Washington, DC: The National Academies Press. doi: 10.17226/13907.
×
Page 18
Page 19
Suggested Citation:"Chapter 2 - Automatic Vehicle Location." National Academies of Sciences, Engineering, and Medicine. 2006. Using Archived AVL-APC Data to Improve Transit Performance and Management. Washington, DC: The National Academies Press. doi: 10.17226/13907.
×
Page 19
Page 20
Suggested Citation:"Chapter 2 - Automatic Vehicle Location." National Academies of Sciences, Engineering, and Medicine. 2006. Using Archived AVL-APC Data to Improve Transit Performance and Management. Washington, DC: The National Academies Press. doi: 10.17226/13907.
×
Page 20

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.

14 TCRP Synthesis of Transit Practice 24: AVL Systems for Bus Transit provides an insightful description of AVL systems and a review of AVL’s history (9). Historically, AVL was developed for two real-time applications: emergency response and computer-aided dispatch (CAD). CAD represents a major advance in complexity, because it involves matching the observed operation to the schedule. AVL has long been adver- tised as a means of obtaining data to be archived for off-line analysis as well. That promise, which has seen limited fulfill- ment, is the focus of this report. 2.1 Location Technology In the last decade, the U.S. government’s global positioning system (GPS) has become the preferred location technology. GPS receivers on vehicles determine their location by triangu- lation based on signals received from orbiting satellites. Loca- tion accuracy for buses is generally better than 10 m, depending on the accuracy of clocks in the GPS receivers and on whether differential corrections are used. Because GPS requires a line of sight to the satellites, GPS signals can be lost as buses pass through canyons, including man-made canyons caused by tall buildings. Tall buildings also reflect GPS signals, causing a phenomenon called multipath that can lead to erroneous location estimation. For example, on a GPS-driven map display, buses approaching Chicago’s Loop (downtown) appear to jump into Lake Michigan. In a system intended for real-time monitoring only, predictable errors such as this can be tolerated; however, for archived data intended for off-line analysis, errors like this pose a threat to data integrity. In tunnels and covered areas, GPS cannot be used unless repeaters are installed, as in NJ Transit’s Newark City Subway. Older AVL-APC systems, like King County Metro’s, use a combination of beacons, which serve as fixed-point location devices, and dead reckoning for determining location between beacons, using the assumption that the bus is following a (known) route. All transit coaches have electronic odometers, making it easy to integrate odometers into a location system. Route deviations present a problem for odometer-based dead reckoning, which is one of the reasons GPS is preferred. Some AVL systems include a gyroscope, which makes it possible to track a bus off-route using dead reckoning. Many GPS-based systems often use dead reckoning as a backup.When GPS signals indicate a change in location incon- sistent with the odometer, dead reckoning takes over from the last reliable GPS measurement, until GPS and odometer meas- urements come back into harmony. Odometers require calibration against known distances measured using signposts or GPS, because the relationship between axle rotations (what is actually measured) and dis- tance covered depends on changeable factors such as tire inflation and wear. 2.2 Route and Schedule Matching Matching a bus’s trajectory to route and schedule is impor- tant for data analysis, as well as many real-time applications including CAD and real-time passenger information systems. The rate at which data is rejected for inability to match it to a route can be substantial, reaching 40% at agencies that were interviewed. Data matching was cited by many agencies as the single greatest challenge faced in making their AVL-APC data useful. Some very simple AVL systems perform no matching; they simply display on a map where the buses are. However, most transit AVL systems include CAD, which involves real-time matching to route and schedule. Because the most demand- ing application in regards to matching is stop announcements (because matching errors are so apparent to the public), archived data derived from stop announcement systems should be of particularly high quality. In traditional APC systems, which lack a real-time compo- nent such as CAD or stop announcements, data is matched C H A P T E R 2 Automatic Vehicle Location

off line based on signpost, odometer, and/or GPS reading recorded during operation. Matching algorithms themselves tend to be proprietary, developed by AVL vendors or (for APC) developed in house. As a general rule, the more data available, and the greater its detail and accuracy, the better the matching accuracy is. 2.2.1 Route/Run Data and Operator Sign-In Matching, whether in real time or off line, is more success- ful when the algorithm doing the matching has prior knowl- edge of the route and schedule the bus is supposed to be following. With the scheduled bus path known, real-time measurements are then used to verify and update the path. If door opening and closing sensors are part of the data collection system, each door opening/closing event suggests that a bus is at a stop, permitting a comparison between reported location and expected next stop location. In newer AVL systems, the schedule and base map infor- mation used for matching are held in the on-board computer. Recognizing that schedules often change, many systems pro- vide for schedule information to be uploaded daily. At King County Metro, where the older AVL system’s on-board com- puters cannot hold the full schedule, buses are tracked against the schedule by the central computer; nevertheless, King County Metro devised and implemented a method for local, real-time matching. About 3 min of running time before each timepoint, the central computer radios to the bus a message indicating the odometer reading at which the coming time- point will be located; local sensing and logic will then suffice to know when the bus has reached the next timepoint. This technique substantially improved King County Metro’s suc- cess at matching timepoints. The main source of route/run data is operator sign-in. Sign-in to radio systems is routine in the transit industry, and non-compliance is generally limited to a small percentage of operators on any given day, because operators who do not sign in can be readily detected at the control center.At King County Metro, for example, operators who fail to sign in can be called out of service for having a faulty radio, and face possible dis- cipline if the problem turns out to be simple failure to sign in. Therefore, AVL systems connected to the radio benefit from getting relatively good-quality sign-in data. The validity of sign-in data can also be a problem. Accu- racy will be better if the system taking the sign-in accepts only valid codes for operator number, run number, and so on. Systems in which sign-in errors are not detected until off-line processing cannot benefit from operators correct- ing their own input errors. As an example, farebox data sys- tems often have very high rates of sign-in error, making boarding counts and revenue difficult for agencies to attrib- ute to route (10). Data collection systems not tied to the radio, like traditional APC systems,present a challenge.Agencies are reluctant to force operators to sign in again to another system when they are already signing in to the radio, farebox, and destination sign; and, if sign-in is not necessary for any real-time operating func- tion, compliance is sure to be an issue. King County Metro solved this problem by connecting its APCs to the radio control head, which transmits sign-in information to the (otherwise independent) APC on-board computer. Lacking sign-in data, NJ Transit’s APC/event recorder sys- tem still tries to take advantage of the scheduled runs that buses follow by using a two-step matching procedure: (1) the route/run is inferred from pull-out, pull-in, and stop records and then (2) the inferred run is used for stop-level matching. If matching fails, the system may guess a different route/run. Metro Transit eases the burden on operators while improv- ing accuracy by providing automated sign-in, communicated by wireless link during pull-out, based on vehicle-block assign- ments made overnight. In its new AVL-APC system, operators are asked only to verify and correct their sign-in information. Houston Metro improves the accuracy of its route/run data by comparing sign-in data with payroll data as part of routine post-processing. A semi-automated procedure allows an ana- lyst to make corrections if there seems to be a simple, cor- rectable error, such as a miskeyed run code. 2.2.2 Base Map Accuracy Without data matching as a driving application, transit agencies have little need historically for an accurate stop data- base. Many agencies have no stop database, because they do not own the stops (i.e., the sidewalk space and signs) and because routes and schedules are detailed only to the time- point level. Before AVL, stop databases only had to be accurate enough for operators and maintenance personnel to locate the stop. However, automatic applications do not forgive errors and omissions the way manual data collection can. Generally, agencies implementing AVL have needed to make a major effort to correct their stop location database. Some agencies and vendors have used dedicated crews to field map all stop locations using mobile GPS units. Buses themselves can be configured to be those mobile units. The 2002 case study of NJ Transit emphasizes the importance of having a good base. On patterns for which at least 90% of the reference locations are coded to within 300 feet of actual, NJ Transit’s matching algorithm was able to match 81% of the trips to a scheduled trip and pattern, in contrast to a 65% matching rate overall. Starting with a well-calibrated GIS base map based on aerial photography can reduce the burden of field mapping. Equally important is maintaining the stop location file for both temporary and permanent changes. Some large agencies report changing 5% of their 10,000 stops each year. 15

While AVL-APC systems need accurate bus stop locations, the location data that AVL-APC systems supply can also be used to improve the base map. One APC vendor recommends comparing average GPS coordinates at observations of a stop to its reference coordinates, updating the base map if the obser- vations are consistent. One complicating factor is that different enterprise systems– scheduling, facilities, transportation, passenger information systems such as on-line trip planners, and traffic manage- ment–use the term “bus stop” for different functions, leading to slightly varying definitions that often entail differing loca- tions. A transit agency can have four or more definitions of stop location (11): • Intersection or landmark (e.g., Third and Main) • Intersection quadrant • Nominal coordinates along an ideal route, often following the roadway centerline • Coordinates of the point on the curb closest to the bus stop sign Additionally, the complication of determining coordinates, which may differ between location system and the base map, introduces a possible calibration problem. A recently pub- lished U.S.DOT report on location referencing offers valuable guidance for making location accurate and consistent across data systems (12). 2.2.3 Schedule Integration Thanks to the near-universal adoption of automated sched- uling, route and schedule data is always imported from the scheduling system. The schedule database tends to be accurate and carefully maintained because of its critical role in opera- tions and payroll. In large cities, transit schedules tend to be extremely dynamic, with route, vehicle, and operator schedules changing almost daily. It is therefore vital to the performance of AVL to have a mechanism for keeping the schedule up to date. Many AVL systems reload the entire schedule to bus on-board com- puters daily at pull-out. Several transit agencies have reported difficulties in inte- grating the schedule database with AVL, sometimes delaying a project for years. The desire for a standard interface was echoed by many transit agency and vendor representatives. Even though there are only two major schedule software suppliers, databases tend to be highly customized to each transit agency’s particular routing, schedule, and work rules practices; there- fore, a standard interface, even for a single scheduling system vendor, can be elusive. In one case, the problem that had to be overcome was that the AVL vendor’s software expected that the schedule data- base would have details concerning the path taken by buses during pull-ins, pull-outs, and deadheads, but the schedul- ing system vendor’s database excluded those details. Another problem is that schedule databases define routes as a series of timepoints, not stops, while an AVL or APC system doing stop-level tracking sees a route as a sequence of stops. 2.2.4 Control-Ordered Schedule Changes Route and schedule matching becomes complicated when buses do not exactly follow their assigned block. Examples are when a bus breaks down, when buses are short-turned or inserted into the schedule to try to balance headways, or when buses swap duties. In such cases, capturing informa- tion about schedule changes ordered by dispatchers can ease the task of matching. If the change is simply that a bus assumes a new block or run, that information can be captured through (a fresh) sign-in. Otherwise, to the researchers’ knowledge, no method has yet been developed for capturing control-ordered schedule changes in a form suitable for automated processing. At King County Metro, for example, the AVL/radio database includes con- troller logs indicating changes to bus and operator assignments; however, those records need to be interpreted manually. 2.2.5 End-of-Line Identification End-of-line operations can be both complex and unpre- dictable, making a trip’s start and end times difficult to identify. One reason such identification is difficult is that terminals are often located where GPS accuracy is worst—near tall down- town buildings or in a covered terminal. A second reason is the unpredictability of operations at route ends. Operators approaching the end of the line with an empty bus may feel free to deviate from the prescribed route (e.g., to stop at a sandwich shop, thereby spending their layover at a different location). At the terminal, an operator getting in and out to adjust a mirror can be mistaken as passengers getting off and on and a stop being served. Operators may open and close doors several times to let passengers board during layover periods, which makes door closing an inadequate criterion for inferring departure from the stop. A vehicle jockeying for posi- tion in a layover area may be mistaken for an early departure. For these reasons, several agencies report treating first and last segment running time data with some skepticism. Some agencies simply exclude first and last segments from running time analysis, forcing them to assume a fixed running time on those extreme segments. Not being able to track operations from the start to the end of a line compromises the integrity of route-level running time analyses such as determining periods of homogeneous running time and the sufficiency of recovery time. Agencies have used various means to improve end-of-line identification. King County Metro made its tracking algorithm 16

ignore bus movements in layover areas that occur more than 3 min before scheduled departure time, because bus move- ments in staging areas were being falsely detected as trip starts. Staff at several agencies recommend locating signposts (real or virtual) not at route terminals, but a few minutes’ travel from the terminal. This arrangement resolves some of the match- ing issues but leaves running time and schedule adherence at the route endpoints unmeasured. (Stop-level data collection effectively accomplishes the same thing.) Records made dur- ing the layover, and algorithms using those clues can help reduce end-of-line matching errors. End-of-line complications also affect passenger count analysis, as discussed in Chapter 8. 2.3 Data Recording: On- or Off-Vehicle One essential distinction within automatic data collection systems is whether data is recorded in an on-board computer or in an off-vehicle central computer to which messages are sent via radio. Historically, AVL systems have been tied to the radio system and have used that connection for off-vehicle data recording. Stand-alone APC systems, in contrast, record data on board. From the viewpoint of a data archive, radio- based systems are limited by radio channel capacity, while on- board storage imposes no meaningful limit on either the number or detail of data records. Until the mid-1990s, on-board data storage was expensive and was therefore avoided. Since then, the cost of adding stor- age capacity to on-board computers has ceased to be a signifi- cant factor in system design. Therefore, newer systems, which sometimes blur the traditional AVL-APC distinction, can be designed with either on- or off-vehicle data recording, or both. In the mid-1990s, Tri-Met made the significant step of specify- ing that its new AVL system both transmit messages by radio to serve real-time applications and store event records on board for off-line analyses. Because of radio channel limitations, radio messages are sent only for exceptions (a bus is more than 3 min late or off route, or an event of interest occurs); on-board recording, in contrast, has no such limitation. 2.3.1 Radio Messages and Record Types Radio systems use a wide area network (WAN) to manage communication between a central computer and on-board computers and radios. They are licensed by the Federal Com- munications Commission (FCC) and have a limited number of radio channels.Limitations are most severe in large cities,where the demand for radio channels (for police, fire, taxi fleets, etc.) is greatest; unfortunately, large cities also have the larger bus fleets and therefore need more radio channels. Transit agencies typically dedicate some channels to voice and others to data; this research concerns the data channels. Because there may be hundreds of buses per radio channel, the radio traffic has to be managed to fit within the available capacity. Polling Records Most real-time AVL systems use round-robin polling to track their vehicles. The polling interval depends on the num- ber of vehicles being tracked per radio channel; 40 to 120 s is typical. Within each polling cycle, every vehicle is polled in turn, and the vehicle responds with a message in a standard format. Round-robin polling is an effective protocol for avoid- ing message collisions; however, the need to transmit messages in both directions, with a time lag at either end for processing and responding, means that a significant amount of time— on the order of 0.5 s—is needed to poll each bus. The polling cycle is therefore limited by the number of buses being monitored per radio channel. A polling message includes ID codes (for the vehicle, its run or block, and perhaps its route) and various fields for location data. Location fields depend on the location system used. For a beacon-based system, they include ID of the most recently passed beacon and odometer reading. For GPS systems, GPS coordinates will be sent, perhaps with odometer reading as well. The polling message often includes other fields such as an operator-activated silent alarm and mechanical alarms such as “engine overheated.” Polling provides location-at-time data (i.e., the location of the bus at the arbitrary time at which it is polled). However, the much more useful time-at-location data (i.e., time at which a bus passes a point of interest such as a stop or timepoint) is the format needed to analyze schedule adherence and running time. While polling data can be interpolated to get estimates of time-at-location data, such interpolation can involve signifi- cant approximation error, especially when buses are traveling at low speeds because of traffic or stopping. In principle, if the polling interval were very short, approximations would become insignificant; however, radio channel capacity limita- tions make short polling intervals impractical. (Many systems can switch to a short polling cycle for particular buses in an emergency, but that can only be done to the detriment of other buses’ polling interval.) The researchers found no examples of transit agencies extracting time-at-location information from polling data or basing any analysis of running time or schedule adherence on it. The only off-line use found for polling data was for detailed investigations of incidents using playback. Event Records In addition to round-robin polling, WANs also support messages initiated at the vehicle, generically called “event 17

messages.” Each event record has a code and specified format. Modern AVL systems can have 100 or more different types of event records. Messages initiated by on-board computers are likely to collide—that is, one bus will try to send a message while the channel is busy with another message. WANs manage this kind of network traffic problem in various ways, such as by having messages automatically re-sent until a receipt message is received. This need to manage traffic limits the practical capacity of radio-based communication, because, with ran- domly arising messages, the channel has to be unoccupied a relatively high fraction of the time (unlike with round-robin polling) to provide an acceptable level of service. In the face of limited channel capacity, then, radio-based systems have to be designed in a way that limits the frequency and length of messages sent. Timepoint Records In most AVL systems, the timepoint event, indicating a bus’s arrival or departure from a timepoint, is the most frequent event record used for archived data analysis. The event can be defined in various ways, depending on the location system. Where GPS is used and door switches are not, it is common to report when the bus first reaches a circular zone (typically a 10-m radius) around the stop. The timepoint record may also include the time the bus left that zone. In principle, timepoint records could also include fields indicating when doors first opened and last closed; however, the researchers are not aware of any radio-based systems incorporating door information. The level of detail of timepoint records affects their accuracy and value for off-line analysis. For example, some running time and schedule adherence measures are defined in terms of departure times, others in terms of arrival times, and others involve a difference between arrival time at one point and departure time at a previous timepoint. Off-line analysis there- fore benefits from having both arrival and departure times recorded, particularly if operators hold at timepoints. Records of when buses enter and depart a stop zone are only approxi- mations of when buses arrive and depart the stop itself. Errors can be significant in congested areas where traffic blocks buses from reaching or pulling out of a stop. Detail on door opening and closing, and on when the wheels stop and start rolling, can help resolve ambiguities and make arrival and departure time determination more accurate. Stop Records Stop events are much more frequent than timepoint events, and therefore, far more demanding of radio channel capacity if transmitted over the air. Therefore, most AVL-APC systems collecting data at the stop-level store stop records in the on- board computer, uploading them overnight. However, some systems, including Metro Transit’s, find enough radio channel capacity to send stop messages over the air, though only for the subset of the fleet (under 20%) instrumented with APCs. The data items typically included in a stop record—in addition to the usual time stamp, location stamp, vehicle IDs, and door switches—are door opening and closing times and (if available) on and off counts. If routes are tracked by the on-board computer, as is the case with stop announcement systems, the stop record will include stop ID in addition to generic location information; otherwise, the data is matched in later processing. Other Event Records Timepoint and stop events are the frequent events that most off-line analysis relies on. Other event records can be valuable, either in their own right or because of the clues they offer for matching. Events whose records can be helpful for matching include the operator signing in, bus passing a beacon, bus going off route, and engine being turned off or on.“Idle”event records, indicating that a bus has not moved for a certain amount of time, are useful for confirming bus behavior at layover points or timepoints. Heartbeat records, written every 30 to 120 min, help confirm that the bus’s data recording system is working. Events of direct interest for off-line analysis include wheel- chair boardings or alightings, bicycle mounting, various delay types (e.g., drawbridge, railroad crossing), and pass-ups. Most such event messages are manually triggered by the operator; although some (e.g., wheelchair lift use) can be automatically generated. 2.3.2 On-Board Data Recording and More Message Types In contrast to radio-based data recording, on-board data recording essentially offers unlimited capacity (because on- board data storage is so inexpensive it is easily obtainable). It is also more robust, not being subject to radio system fail- ure. (Some radio-based systems, such as Metro Transit’s, include backup on-board data storage during periods of radio failure to prevent data loss. Event records stored on board are uploaded at pull-in using the radio system and merged into the event database.) Radio Integration and Operator-Initiated Data Expecting operators to key in event data that is used for data archiving only is considered unrealistic. Therefore, event records are generally limited to what can be automatically generated, unless the on-board computer is connected to the 18

radio, in which case it can also capture operator sign-in and operator-initiated events. Several AVL-APC systems feature this arrangement, which helps facilitate matching and yields a richer database. On-board integration with the radio control head is recommended even if there is no real-time AVL. Off-line, radio-based event records also can conceivably be integrated with records uploaded from the on-board com- puter. However, the researchers are not aware of this design being used. Interstop Records and Detailed Tracking With on-board data collection, data can also be collected between stops. One data collection mode is to make records very frequently (e.g., every 2 s); this mode uses buses as GPS probes, which can enable such special investigations as study- ing the bus’s path through a new shopping center or studying bus movements in a terminal area. Frequent interstop records also offer information on speed and acceleration. An alternative data collection mode is to write event records for defined events that can occur between stops, such as cross- ing a speed threshold. To measure delay, Eindhoven’s system records whenever a bus’s speed rises above 5 km/h or falls below 4 km/h. (Using differing thresholds prevents oscillation when the bus is traveling at the threshold speed.) Records for a variety of speed thresholds could be useful for analyzing speed profiles. Tri-Met’s system tries to capture maximum speed between stops, both as a measure of traffic flow and as a safety indicator. It tracks speed continuously, storing the greatest speed since the last stop in a temporary register; then at each stop, maximum speed since the previous stop is recorded. Data Uploading When data is recorded on vehicle, there has to be a system for uploading the data from the on-board computer to the central computer. Newer systems usually include an auto- matic high-speed communication device through which data is uploaded daily when buses are fueled. Older systems such as Tri-Met’s rely on manual intervention, such as exchanging data cards or attaching an upload device, which adds a logis- tical complication. The absence of an effective upload mechanism can render an otherwise promising data collection system useless for off-line data analysis. One transit agency has a new stop announcement system that records departures from every stop. However, the data is overwritten every day, because the data logging feature was intended for system debugging, not data archiving. To make it an archived data source, the agency would have to either exchange cassettes nightly, something it deemed imprac- tical, or invest in a high-speed data transfer link, something it found too expensive. Communication is also needed from the central computer to the on-board computer, whether for occasional software upgrades or daily schedule updates. In general, the communi- cation method used for upload is used for download as well. 2.3.3 Exception-Only Data Recording Some AVL systems send timepoint messages only if a bus is off schedule, partly to limit radio traffic, and partly because controllers are usually interested only in service that is off schedule. For example, Tri-Met’s AVL-APC system transmits only exception messages by radio, while saving a full set of records on board for later analysis. However, if exception data is all that is available for off-line analysis, analysis possibilities become severely limited. For example, if only off-schedule buses create timepoint records, running times can only be measured for off-schedule buses. Researchers at Morgan State University tested the feasibility of data analysis using exception data from bus routes in Bal- timore, MD (13). Because they had records only on buses that were outside an on-time window, they focused on next-segment running time for buses that arrived at a timepoint early or late. If the bus reached the next timepoint “on time,” the researchers had to guess when within the on-time window the bus arrived. Also, because the system archived only exception messages, it was impossible to know whether a missing record meant that a bus was on time or that the radio system had failed. In an interview, the Morgan State researchers stated that while the Mass Transit Administration (MTA) had asked them to systematize the way they trans- formed the raw data into records that would support analy- ses of running time and schedule adherence, they felt it was impossible given the frequent need for assumptions to make up for missing data. Fortunately, advances in radio technology have reduced the pressure to limit data collection to exceptions. As an example, CTA’s real-time AVL system, specified in 1993 to provide loca- tion data only if buses were off schedule, was modified in 2002 so that buses transmit location data regardless of whether they are off schedule. 2.4 Data Recovery and Sample Size Automatic data collection systems do not offer 100% data recovery. Traditional APCs have the worst record; a 1998 sur- vey found net recovery rates for APCs ranged from 25% to 75%, with newer systems having better recovery rates (14). In 1993, the Central Ohio Transit Authority (COTA) reported that, with 11.9% of the fleet APC equipped, it netted on average five usable samples per assignment each quarter (15). That rep- resents a 6.1% sampling rate, for a net recovery rate of about 50%. Only a small part of that loss was due to mechanical 19

failures, as mechanical reliability was reported to be well above 90%. Less is known about data recovery rates for radio-based AVL systems. King County Metro recovers AVL data from about 80% of its scheduled trips. However, with the entire fleet instrumented, data recovery rates are not so important with AVL unless there is systematic data loss in particular regions. Inability to match data in space and time is the single most cited reason for rejecting data. There are other reasons, including malfunctioning on-board equipment, data being out of range, radio failure, and so forth. Imbalance in pas- senger counts, another common problem that forces data to be rejected, is covered in Chapter 8. The effective sampling rate of an AVL-APC system is the fleet penetration rate multiplied by the data recovery rate. If 10% of the fleet is equipped, and data is recovered from 70% of the instrumented vehicles, scheduled trips will be observed, on average, 10% * 70% = 7% of the number of times they are oper- ated. In a 3-month period containing 65 weekdays, 13 Satur- days, and 13 Sundays, average observations per scheduled trip will be 4.5 for weekday and just under 1 for Saturday and Sunday trips. An average sampling rate can mask significant variations across the system. When fleet penetration is small, logisti- cal difficulties coupled with the vagaries of data recovery failure often result in some scheduled trips being sampled well more than the average number of times, and others perhaps going completely unobserved. Management of the rotation of the instrumented vehicles, then, becomes another important factor in determining whether needed data will be available. In an example drawn from the project’s case studies, an audit of King County Metro’s Fall 1998 sign-up (a 4-month period) found on average six valid APC observations per weekday scheduled trip, for a sampling rate of 7.5%. With about 15% of the fleet instrumented, that represents a data recovery rate of 50%. Coverage across the schedule was variable. King County Metro recovered at least one valid observation on 97% of their scheduled weekday trips, and at least three valid observations for 83% of its scheduled weekday trips. On the weekend, 85% of scheduled trips had at least one valid observation. In 2002, King County Metro reported that its recovery rate had improved to the 60% to 70% range. In general, a small sample size is sufficient to reliably esti- mate the mean of a quantity with low variation such as run- ning time on a segment or demand on a particular scheduled trip. In contrast, a large sample size is needed to examine vari- ability or extreme values, such as the 90-percentile running time or load. A very large sample size is needed to accurately estimate proportions, such as proportion of departures that are on time (16). Analyses that aggregate scheduled trips into periods, or that aggregate routes, have the advantage of a larger sample size than analyses of individual scheduled trips. For this reason, many customary analysis methods, developed in a limited-data environment, find results for the period rather than the trip, and for the system rather than the route. A large sampling rate allows more timely analysis of data. Over a long enough period of time, even a small sampling rate will yield a large number of observations. However, for management to react promptly to demand and performance changes, or measure the impact of operation changes, analysts need recent data. Therefore, tools used in the active manage- ment of a dynamic system will benefit from the high sampling rate that follows when the entire fleet is equipped. Because leader-follower or headway analysis requires valid observations of consecutive pairs of trips, the number of valid headways one can expect to recover is proportional to the square of the data recovery rate and the correct assignment rate. For example, if the data recovery rate is 70% and if a request to instrument a given route results in 90% of the trips on that route having an instrumented bus, one can expect to observe only (0.7)2 * (0.9)2 = 40% of the day’s headways on that route. If there is a realistic possibility of trips overtaking each other, having anything less than data from all the operated trips casts some doubt on calculated headways. 20

Next: Chapter 3 - Integrating Other Devices »
Using Archived AVL-APC Data to Improve Transit Performance and Management Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's Transit Cooperative Research Program (TCRP) Report 113: Using Archived AVL-APC Data to Improve Transit Performance and Management explores the effective collection and use of archived automatic vehicle location (AVL) and automatic passenger counter (APC) data to improve the performance and management of transit systems. Spreadsheet files are available on the web that provide prototype analyses of long and short passenger waiting time using AVL data and passenger crowding using APC data. Case studies on the use of AVL and APC data have previously been published as appendixes to TCRP Web-Only Document 23: Uses of Archived AVL-APC Data to Improve Transit Performance and Management: Review and Potential.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!