AVL Systems for Bus Transit: Update (2008)

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.

91 GENERAL ROLE WITHIN AGENCIES The core role of a bus automatic vehicle location (AVL) sys- tem, whether for fixed-route or paratransit (demand respon- sive) operations, is to support operators, supervisors, and dis- patchers during their real-time fleet operations management. As these systems typically provide to dispatch real-time op- erations support data well beyond simply fleet location, they are often referred as AVL systems. In addition, these systems often collect service planning support data, provide real-time customer information, and support onboard integration with other systems. Figure B1 shows a high level overview for a generalized bus AVL system, as defined for the purposes of this synthe- sis. This system includes a mobile communications system supporting data exchange between fleet vehicles and central computer system, as well as the dissemination of real-time customer information from the central computer system via dynamic message sign (DMS) at selected stops. FIXED ROUTE For fixed-route operations, a typical AVL system supports real-time fleet operations management by providing operators with real-time schedule adherence feedback and by providing dispatchers with real-time data on the locations and status of all fleet vehicles (typically including both revenue and non- revenue vehicles). Voice and data communication manage- ment between dispatchers and fleet vehicles is usually also incorporated into the AVL system. The onboard equipment is sometimes integrated with automatic passenger counter (APC) and automated next stop announcements. AVL and APC data are commonly archived for management analysis. The system can provide real-time customer information based on the fleet location and schedule adherence data using meth- ods such as DMS at selected stops. The system can also pro- vide real-time customer information through additional meth- ods defined as outside the boundaries of a bus AVL system as defined for the purposes of this synthesis, including interac- tive voice response (IVR) telephone information systems and web-based applications. PARATRANSIT For paratransit operations, the AVL system is commonly inte- grated with specialized paratransit software for scheduling and dispatch operations management, which supports trip book- ing, run scheduling, and same-day changes. The onboard op- erator interface focuses on displaying the manifest of upcom- ing pickups and dropoffs, and allowing the operator to send in real-time data as manifest trip events are completed. The sys- tem can provide real-time customer information for trip book- ing, confirmation, cancellation, and for vehicle approach, using methods such as IVR telephone information systems and web- based applications. FUNCTIONAL CAPABILITIES This section provides additional detail on typical functional capabilities for an AVL system that supports fixed-route and paratransit operations: • Onboard—Fixed-Route Vehicles – Log in to a run; – Log in simultaneously to the AVL system and other onboard devices requiring operator login (e.g., fare- box and headsign); – Continuously determine location in real time; – Track schedule and route adherence and transmit these data to the operator; – Send location, schedule adherence, and route adherence status and other status data to dispatch on a frequent periodic basis (note that the specific polling interval, such as to get a report from the entire fleet every 90 s, is usually determined by the capacity of the mobile data communications system); – Send canned text messages from operator to dispatch; – Send operator request for a voice call from dispatch; – Send operator input on the routes boarding passen- gers will transfer to, and receive feedback on the transfer connection protection (TCP) status for these requests; – Allow the operator to covertly send an emergency alarm data message; – Provide route and trip segmentation and fareset data to the farebox; – Automatically change the headsign destination at the end of trips; – Provide automated passenger interior announcements of the stop name as the vehicle approaches; – Provide automated passenger exterior announcements of the route and destination once the door opens at a stop; – Collect APC data, recording the number of passen- gers boarding and alighting through each door at each stop (based on these data, the system sometimes also tracks the current onboard load); – Use schedule adherence status to request TSP only when the vehicle is running late; and APPENDIX B Overview of Current Bus AVL Systems

– Monitor the mechanical status of key components (i.e., from mechanical sensors or electronic control units for components such as engine, transmission, and air con- ditioning), recording the data and/or transmitting to dispatch. • Onboard—Paratransit Vehicles – Log in to a run; – Determine location in real time; – Receive manifest of pickups and dropoffs, and man- ifest changes; – Send real-time updates as manifest trip events are completed; – Send canned text messages from operator to dispatch; and – Send operator request for a voice call from dispatch. • Onboard—Non-Revenue Vehicles – Log in; – Determine location in real time; – Send canned text messages from operator to dispatch; and – Send operator request for a voice call from dispatch. • Central Systems – Show real-time current fleet locations, schedule adher- ence, route adherence, and other fleet status events to dispatchers, using a map and tabular displays; – Provide the ability to manage the work assignments of multiple dispatchers and to support a strategy of par- ticular dispatchers managing given vehicles, routes, or zones; – Send canned or free-form text messages to one or more operators; – Initiate voice calls to one or more operators, when- ever needed, and on receiving a voice call Request to Talk (RTT) from an operator; – Receive TCP requests from inbound fixed-route ve- hicles, provide feedback on the status of these re- quests, and issue hold instructions to outbound vehi- cles when needed; – Listen to audio from a vehicle that sent in a covert emergency alarm; – Log the disposition of and actions taken in response to fleet status events; – Create and log incident reports; – Support mobile workstations in non-revenue vehicles that can provide a limited functional version of dis- patcher software, supporting fleet monitoring, text messaging, logging, incident reports, and playback; 92 – Provide information for customer service agents to help address customer questions and concerns, in- cluding the ability to “play back” the movements and status of a selected vehicle over a given period; – Provide information to maintenance managers to assist in directing road call vehicles to the locations of buses requiring service; – Build a historical database that includes vehicle loca- tion, vehicle status, logs, incident reports, and APC data; – Periodically generate a variety of canned reports and provide a method to generate ad hoc reports (the ef- fective definition of useful canned reports requires input from agency business units during the imple- mentation, and the ongoing effective generation of ad hoc reports requires that the agency develop in-house expertise with the system databases and the ad hoc reporting tools); – Interface with paratransit operations software for scheduling and dispatch management to exchange manifest and trip completion data between this soft- ware and paratransit vehicles; and – Use schedule adherence and location data to develop real-time predictions for bus arrival times at stops and to provide these predicted arrival times to customers. • Selected stops – Use DMS to provide next arrival predictions and other real-time customer information (e.g., delays). SYSTEM COMPONENTS In general a current generation bus AVL system, based on the AVL system boundaries as defined for this synthesis, includes the following system components: • Onboard—Fixed-Route Revenue Vehicles (see Fig- ure B2) – Global positioning system (GPS) receiver and antenna; – Additional “dead reckoning” devices to complement the GPS receiver for vehicle positioning; the most common is integration with the vehicle odometer, with another option being a heading sensor such as a compass or gyroscope; – Vehicle logic unit (VLU) computer; – Mobile data terminal (MDT) operator interface terminal; FIGURE B1 Generalized AVL system overview. AVL Central System Mobile Data Communications System Dynamic Message Signs at Selected StopsAVL Onboard System for Fleet Vehicles Other Non-AVL Systems

93 – One or more radios to provide wide-area voice and data communications; and – WLAN card to provide bulk data communications at the garage. • Central Systems: – Servers, workstations, and network; – Mobile workstations for selected non-revenue vehicles; – Mobile communications gateways; – WLAN access points network at garages; – Dispatcher software with map and tabular displays showing real-time fleet locations, schedule adherence, and other fleet status information; – APC management software, referring to the software used to manage the processing of APC data received from fleet vehicles; – Software to record and set the text for onboard an- nouncements (some systems use text-to-speech soft- ware instead of recording for the audio announce- ments); – Central database; and – Management software for real-time customer infor- mation. • Selected Stops – DMS to present next arrival predictions and other real- time customer information (e.g., delays and AMBER Alert messages). MOBILE COMMUNICATIONS Mobile data communications provide the means for the data communications between components on the vehicle and for vehicles (and also often the DMS at stops) to exchange data with the central system. As such, mobile data communications Mobile Data Terminal Vehicle Logic Unit WLAN Card and Antenna Radio(s) and Antenna(s) Odometer TSP Emitter GPS Receiver and Antenna Vehicle Area Network Farebox Headsign APC Controller Automated Announcements Controller APC Doorway Sensor APC Doorway Sensor Interior DMS Interior Speakers Covert Alarm Switch and Microphone Exterior Speakers Interior Volume Control Microphone Door Sensors FIGURE B2 Fixed-route vehicle system components. WLAN Card and Antenna Mobile Data Terminal Vehicle Logic Unit Radio(s) and Antenna(s) Odometer GPS Receiver and Antenna FIGURE B3 Non-revenue vehicle and paratransit revenue vehicle system components. – One or more radios and antennas to provide wide- area voice and data communications; – Wireless local area network (WLAN) (card and an- tenna to provide bulk data communications at the garage (the use of standard 802.11x WLAN technol- ogy for this purpose has in recent deployments largely superseded the earlier use of physical data transfer using memory cards, although such technologies are still in use in many in-service systems); – APC subsystem, including doorway sensors and controller; – Automated onboard announcements subsystem, in- cluding DMS, speakers, and controller; – TSP emitter; and – Data network to support communications between onboard devices. • Onboard—Non-Revenue Vehicles and Paratransit Rev- enue Vehicles (see Figure B3) – GPS receivers; – VLU computer; – MDT operator interface terminal;

in this sense covers all system communications beyond the wired Local Area Network (LAN) on agency premises and will be discussed in the following categories: • Onboard • Wide area • Garage bulk data transfer. Onboard Communications Onboard data communications between components typically use wired connections. Some vehicle signals are monitored for discrete state changes (e.g., door sensor relays) or analog out- puts (e.g., odometer pulses). Some onboard AVL system com- ponents are directly connected to the VLU as a peripheral device (e.g., MDT and radio), using a serial communications link based on a common computer industry standard such as IEEE RS-232 or in some cases a proprietary interface. For such interfaces, even when IEEE RS-232 or a similar standard is used this typically only defines the physical interface; the software interface is typically proprietary. Onboard components in the AVL system from multiple vendors are commonly interconnected using a standards-based serial communications data network to help support interoper- ability, with many implemented onboard networks for buses conforming to SAE J1708/J1587 or SAE J1939 standard. The most commonly deployed vehicle area network for bus AVL onboard equipment in recent years has been the SAE J1708/J1587 standard. This standard supports interoperability to the extent that SAE J1708 defines the physical interface and SAE J1587 defines a standard set of data messages compatible with transmission over an SAE J1708 network. However, the SAE J1708/J1587 onboard communications software with any particular device typically only supports a subset of the over- all SAE J1587 message set and the use of certain message types that allow for customized content. As a result, it is essential that all onboard devices using SAE J1708/J1587 communications be supplied with sufficient documentation of the specific messages used to allow another vendor to com- municate with it over the vehicle area network. An emerging trend in onboard communications is the po- tential for using an alternative wired network or a short-range wireless standard. • The primary alternative for a wired onboard network is an IEEE 802.3 Ethernet network. With an Ethernet on- board LAN, devices can use networking technologies common in the overall information technology industry such as Transmission Control Protocol/Internet Protocol (TCP/IP) and operate with a higher bandwidth. However, this requires use of the same type of cabling typical for an office LAN, which is thicker than J1708 cabling and poses some limitations for onboard use related to being pulled through tight spaces and the extra weight. 94 • The options for wireless onboard communications in- clude using a standard IEEE 802.11x WLAN (i.e., Wi- Fi) or one of the other “Personal Area Networks” short- range communications technologies [e.g., Bluetooth and Zigbee (B1)]. Wide-Area Communications Radio Voice Most urban bus transit agencies have had a voice radio wide- area communications system in place for decades, having been granted control of one or more radio channels by the Federal Communications Commission (or similar governmental regu- latory agencies outside of the United States). Each radio chan- nel consists of a frequency pair and supports bi-directional communications. These channels commonly use frequencies in the 450, 700, 800, or 900 MHz bands. Conventionally, bus transit voice radio systems have allowed any radio user (e.g., dispatch, supervisors, and operators) to initiate a voice trans- mission whenever the channel is available, and to hear any voice transmission on the channel (commonly referred to as “open voice”). This can be provided by dedicating each radio channel to a certain set of users. Alternatively, a set of radio channels can be “trunked,” wherein a radio control system temporarily assigns one of the channels when a radio needs to initiate a call (voice transmissions can be heard by other radios configured as part of the same “talkgroup”). Open voice operation is challenging for dispatchers, as it is difficult to effectively monitor simulta- neous communications from operators and supervisors. Coverage is accomplished with antennas mounted on an array of towers distributed throughout the transit agency ser- vice area; that is, each tower covers a certain radius. The tow- ers, antennas, and associated tower site infrastructure are in some cases owned by the transit agencies but are often leased from tower site owners. The voice radio audio is carried to the towers by: • Transmission of a signal from dispatch that is received and “repeated” from the tower (and the reverse for in- bound transmissions from vehicles), or • Use of communications links (typically leased) between dispatch and the towers. Cellular Voice Cellular phones are available as an alternative to radio for wide-area voice communications. It is challenging for dis- patchers to manage cellular phone use for fleet voice com- munications (i.e., receiving multiple calls at the same time). Common reasons for using cellular phones, instead of or to complement a voice radio system, include:

95 • Operating in a relatively extensive or rural service area where setting up voice radio communications infra- structure would be relatively expensive, • Expanding into a new service area, and • Initiating a new or small transit service. Radio Data A bus AVL system requires mobile data communications be- tween the central system and operating fleet vehicles, and often also for communications between the central system and the DMS at selected stops. This supports the various real-time data communications that a bus AVL system requires. Another common function is to use mobile data communi- cations to support dispatcher-managed initiation of voice calls. A dispatcher can initiate a voice call to one or more fleet vehicles whenever needed, but a fleet vehicle can only send an “RTT” data message to dispatch (there is also often a “Priority Request to Talk (PRTT)” message that vehicles can use in prescribed situations). Dispatchers initiate two-way voice calls in response to the received RTT and PRTT mes- sages. When individual dispatchers need to listen to all in- coming voice transmissions from a larger number of vehicles, dispatcher-managed voice calls tend to be considered more needed. Some bus AVL systems also use data communications to manage use of the voice radio system for the covert alarm function. When the vehicle operator presses this alarm switch, it sends a data message to dispatch. In addition to signaling to dispatch the emergency vehicle status, when a vehicle is in emergency mode dispatch it often has the additional capability to receive one-way inbound audio over a voice frequency from a covert microphone in the operator area (i.e., to help dispatch assess the emergency without using a two-way voice call that could potentially exacerbate the onboard emergency). Each fleet vehicle can be equipped with two radios: one for voice and one for data. However, agencies often avoid the ad- ditional capital expense by using the onboard system to control the shared use of a single radio between voice and data. Be- cause data are frequently being exchanged between the vehi- cles and central dispatch (e.g., for periodic location and status reports), the radio typically uses data mode as the default state. When dispatch initiates a voice call with a particular vehicle, this system sends a data message to the vehicle that commands it to switch the radio to voice mode for a defined interval. While the radio is temporarily in voice mode, data communi- cations with the vehicle is not available (except for the option of sending brief bursts of data that would interfere with audio transmissions). While monitoring the covert microphone in emergency mode, the system must periodically interrupt the audio transmission so that the radio does not overheat from transmitting continuously; this brief interruption is commonly used to send a location and status update. One or more dedicated radio channels are normally set up for data, one or more of which the agency could opt to convert from current voice communications use. Channels cannot be readily shared between voice and data use because with a shared channel all vehicles in the fleet would need to stop transmitting data to allow a voice call on the channel to trans- mit it without interference. For the same reason, data channels must be kept separate from the pool of channels used for voice communications in a trunked voice system. Trunked radio sys- tems inherently include a limited data transmission capability (i.e., a radio sent data to the trunking control system to request assignment of a voice channel); however, this data capacity is usually not considered adequate to support a bus AVL system. The number of radio data channels needed for an AVL system depends on factors including the fleet size, polling rate (e.g., all vehicles in the fleet are polled every 90 s), and the efficiency of the polling algorithm used in a particular AVL system. Cellular Data As with voice communications, cellular data service is avail- able in most areas as an alternative to radio system data com- munications. This might be done, for example, if the addi- tional radio channels needed to support data communications were not available from the Federal Communications Com- mission or if data coverage was needed in an area beyond the coverage provided by available towers. Cellular data plans providing 5 MB per vehicle per month have generally been found suitable for supporting a bus AVL system, although the specific data capacity required will depend on the details of how the data system is used (e.g., location and status re- ports frequency and extent of text messaging use). Cellular data provide a higher data transmission rate than is usually available with data transmission over radio chan- nels [common radio system data rate is 9.6 kilobits per second (kbps)]. A typical cellular data system that is currently widely deployed in the United States is Evolution—Data Opti- mized (EVDO) Rev 0, with theoretical maximum data rate at 2.4 megabits per second (Mbps), with 300–600 kbps more common in practical use (B2). Agency concerns with cellular data include the monthly account fees and the poten- tial for cellular systems to sometimes become overloaded dur- ing emergencies (i.e., owing to the infrastructure being shared with the general public). In comparing monthly costs with the radio alternative, agencies should take into consideration the operating and maintenance costs involved in having a radio communications system. Some AVL systems now equip one or more supervisors with a limited functionality version of the dispatcher AVL software, operating on a laptop computer in their vehicle. This provides supervisors with enhanced abilities (e.g., more read- ily able to locate fleet vehicles and monitor schedule/route adherence, and complete incident reports). Such a mobile AVL workstation requires the additional data transmission

rate supported by cellular data for effective operation (and to avoid overwhelming the data capacity available with radio data channels). In some cases, agencies have adopted the use of cellular data for this role, while using radio system data transmission otherwise. High Data Rate Alternatives In recent years, additional high data rate mobile communica- tions alternatives have been emerging. These alternatives in- clude “mesh” networks incorporating various technologies. • One approach uses 900 MHz radio technology, which can be thought of as a higher data rate radio system (1–3 Mbps) that needs a higher density of access points (analogous to radio system towers) because of the re- duced coverage from each access point. • A similar approach would use IEEE 802.11x WLAN “hotspots” instead. Relative to 900 MHz access points, IEEE 802.11x access points offer higher data rates and reduced coverage per access point [e.g., an IEEE 802.11g access point offers a theoretical maximum data rate of 54 Mbps up to about 90 ft (B3), with the data rate step- ping down at greater range]. A limitation with using this approach for mobile data communications is that the IEEE 802.11x WLAN technology was not explicitly de- signed for mobile access, meaning that it is difficult to maintain the connection once the vehicle is moving at any significant speed. • The “mesh” aspect frequently incorporated into such systems refers to the fact that every access point need not have a direct communications link back to dispatch (commonly called the “network backhaul”), thereby re- ducing the cost considering the large number of dis- persed access points involved. Instead, some access points act as repeaters to pass the communications wire- lessly to an access point that has a network backhaul. In a mesh network, users can configure the system with the onboard data communications system equipment serv- ing as additional repeaters. • In some networks, some of the access points that con- centrate data traffic from other access points (i.e., using mesh technology) may not have a wired network backhaul. Instead, they may use a high-capacity data link to send the data to where it can connect with the wired network backhaul. IEEE 802.16 (WiMax) is a communications technology often used in this role, be- cause it can transmit a high data rate and over a longer distance—40 Mbps out to about 10 km (B4). • Conventional IEEE 802.16 WiMax has the limitation (similar to IEEE 802.11x WLANs) that it was not explic- itly designed for use with moving vehicles. An emerging development is IEEE 802.16e Mobile WiMax, which supports connection with moving vehicles, up to about 120 km per hour (B5). This suggests that in time Mobile WiMax could be used for direct communication with the 96 vehicles (i.e., eliminating the role of 900 MHz technol- ogy or IEEE 802.11x WLANs). A transit agency could implement this type of high data rate wide-area mobile communications network on its own or in collaboration with other public sector partners in its region (i.e., analogous to the conventional approach with radio sys- tems). It could also lease an account to use a commercial sys- tem, if such systems become established in its region (i.e., analogous to leased cellular data approaches available today). Any agency intentions to create an IEEE 802.11x WLAN hotspot onboard vehicles for public Internet access, although not addressed in this synthesis, would certainly affect agency decisions related to the most effective wide-area mobile data system. Garage Bulk Data Transfer Many bus AVL systems support bulk data transfer at vehicle storage areas, such as their bus garages. This typically involves setting up an IEEE 802.11x WLAN, because this technology can operate effectively with vehicles that are stopped or mov- ing at low speeds. The role of this bulk data transfer zone is to provide a reg- ular opportunity (e.g., daily) to exchange with each vehicle the following data that do not require real-time transmission, to relieve the volume of data transmission that needs to be ac- commodated with the wide-area mobile data communications system: • Bulk data to be downloaded to vehicles, including firm- ware updates and configuration data updates (e.g., run schedules and automated announcement audio files). • Bulk data to be uploaded from vehicles, including APC data (although some bus AVL systems opt to transmit APC in real time if the data communications system can support this) and maintenance monitoring data (i.e., for maintenance data that there is no need to collect before the bus returns to the garage). Important considerations in implementing such garage bulk data transfer systems include: • The challenge in deciding which type of IEEE 802.11x WLAN technology to use. – IEEE 802.11g offers the increased maximum theoret- ical data rate of 54 Mbps relative to the 11 Mbps max- imum rate available from IEEE 802.11b technology. However, this increased data rate is only available within a more limited range from each access point (i.e., an IEEE 802.11g WLAN network would require more access points than an IEEE 802.11b network to provide the increased data rate throughout the cover- age area).

97 – Many bus AVL systems integrators offer proven off- the-shelf support for the integration of IEEE 802.11b access cards with their VLUs, but in many cases inte- grators have not yet upgraded their standard solution to support IEEE 802.11g. – Meanwhile, IEEE 802.11n, although still at the pre- standard stage, appears to be emerging as the next IEEE 802.11x WLAN technology that will be de- ployed on a widespread commercial basis. IEEE 802.11n WLAN technology is expected to provide a combination of range, throughput rate, and security that will be attractive, but will pose similar transitional issues as noted previously with adoption into the stan- dard products of the bus AVL systems integrators. • Security is essential because agencies will directly inter- face the garage WLAN network with the agency LAN, with key considerations being the technical approach to firewalls, encryption, and authentication. • Communications and power cabling to the WLAN ac- cess points are key issues, especially if there is a large number of access points to cover an extensive vehicle storage area. As discussed previously, mesh networking technology on a garage-level scale for the WLAN access points network can be considered as a method to avoid the need to run cabling to the more challenging garage access point locations. • Agencies must carefully design the access points net- work and channel configurations to avoid channel inter- ference between access points with overlapping cover- age of an area and to address and mitigate WLAN interference sources that may exist from other WLANs operating in the vicinity. INTEGRATION WITH OTHER SYSTEMS This section discusses some of the potential for integration between the bus AVL system, as defined for this synthesis, and other systems. These can be for existing or other future systems, including those onboard the vehicle, and those can be installed by the agency or operated by third parties. Onboard Video Surveillance Integrators can link a set of onboard video cameras with an onboard video recorder. The onboard recorder could be inter- faced with the VLU by means of SAE J1708 or Ethernet link to allow recording of additional data with each video frame (e.g., GPS location, block/run/route/trip/driver identification, and covert alarm status). This interface could also allow trans- mission of alarm status data from the onboard recorder to the VLU using the mobile data communications system. One further area of potential integration is that the onboard video recorder might use the mobile data communications system to send selected video segments. Beyond the use of the garage bulk data transfer system, further mobile video transmission would only typically be viable with a high-data throughput system in place. Farebox and Smart Card Technology Most fixed-route vehicles have a farebox, many of which are of the more modern electronic type. With an electronic fare- box, the operator needs to login at the beginning of a run, which allows the system to record the run with the fare data and to use the correct fareset. During operation, operators are then supposed to press a button on the farebox at the end of each trip of the run, so that the system can use this run seg- mentation data to allocate the fares collected to each trip. Modern fareboxes can be interfaced with the VLU by means of the SAE J1708 link. Once the operator has logged into the VLU using the MDT, the system can use these data to simultaneously login the farebox. As the VLU automati- cally monitors the completion of each trip, this segmentation data can also be automatically provided to the farebox. This interface could also allow transmission of alarm status data from the farebox from the VLU using the mobile data com- munications system. One further area of potential integration is that the farebox might use the mobile data communications system to send its accumulated revenue data. Farebox integration is not yet widely implemented in bus AVL systems. In the survey responses to Question 6, 21% of the respondents indicated that farebox integration was a fea- ture of their AVL system, with the breakdown by time period increasing from 3% installed in 1998–2000, to 9% in 2001– 2003, and to 9% in 2004 or later. The incorporation of this feature continues to increase. In the survey responses to Ques- tion 5, 19% of the responses for agencies currently enhancing an existing AVL system indicated that farebox integration was included in the enhancements. Some agencies have begun to accept fare payment through a smart card period pass or stored value card, in addition to the acceptance of cash (and in some cases magnetic stripe fare media) by means of the farebox. Some smart card readers are integrated into the farebox, and in other cases the reader is a stand-alone device. If the stand-alone is used, it would need to be separately integrated with the VLU. Headsigns Most fixed-route vehicles have a headsign (exterior destination sign at the head of the vehicle), many of which are of the more modern electronic type. With an electronic headsign, the oper- ator needs to log in to the headsign controller at the beginning of a run, which allows the correct destination to be displayed for the initial trip. During operation, operators are then supposed

to press a button on the headsign controller at the end of each trip of the run, so that the destination is updated. Systems can interface modern headsigns with the VLU by means of the SAE J1708 link. Once the operator has logged into the VLU using the MDT, it can use these data to simul- taneously log in the headsign. As the onboard AVL system automatically detects the completion of each trip, it can pro- vide this update to the headsign. This interface could also allow transmission of alarm status data from the headsign to the VLU using the mobile data communications system. Headsign integration is not yet widely implemented in bus AVL systems. In the survey responses to Question 6, 28% of the respondents indicated that headsign integration was a fea- ture of their AVL system, with the breakdown by time period increasing from 3% installed in 1997 or earlier, to 6% in 1998–2000, to 6% in 2001–2003, and to 16% in 2004 or later (some agencies installed in multiple time periods). The incor- poration of this feature continues to increase. In the survey re- sponses to Question 5, 25% of the responses for agencies cur- rently enhancing an existing AVL system indicated that headsign integration was included in the enhancements. Agency Central Systems Fixed-Route Scheduling Software This software is used by an agency to enter its timepoint lo- cations, stop locations, trip patterns, and running times, and to provide computer assistance with defining routes, trips, inter- lining, blocks (the daily work of a vehicle), runs (the daily work of an operator) and rosters (multi-day operator work packages). These together constitute the scheduling of the fixed-route service. The onboard VLU of the bus AVL system requires the schedule and route data for all runs. Schedule data typically consist of the schedule arrival or departure time for each time- point. When an operator uses the MDT to log into a run, the VLU can then use these data together with the ongoing GPS receiver location data to track route and schedule adherence. Agencies typically update their schedules every 3 to 6 months. Integration between the AVL system and fixed- route scheduling is needed to support transferring run schedule data into the AVL system. The fixed-route scheduling software needs to create an export file, which can in turn be imported by the AVL system. In systems with a garage bulk data transfer WLAN, buses routinely check that they are carrying the most up-to-date schedule files and download the updated file when needed. In systems without garage WLAN, the system may download schedule updates in fragments over the wide-area mobile data system or use a manual procedure with physical memory media (i.e., memory card or stick). 98 The number of AVL systems with WLAN bulk data trans- fer capability is increasing. In the survey responses to Ques- tion 6, 41% of the responses indicated that this was a feature of their AVL system—with the breakdown by time period increasing from 9% installed in 1998–2000, to 13% in 2001– 2003, and to 19% in 2004 or later. In the survey responses to Question 5, 31% of the responses for agencies currently enhancing an existing AVL system indicated that WLAN in- tegration was included in the enhancements. There are many older systems still using physical memory media. These older systems work so an upgrade is not essen- tial, but many agencies would like to avoid the time needed to physically visit each bus with the memory media. As discussed in the section about garage bulk data transfer communications, agencies must carefully consider network security when set- ting up a garage WLAN. If an agency does not have such fixed-route scheduling software, the schedule data periodically required by the on- board VLUs will somehow need to be created. Therefore, the process of getting the required data into the onboard VLUs will be facilitated by implementing such software. Garage Operations Software This software helps facilitate and track the assignment of ve- hicles to blocks and of operators to runs (and thus the assign- ment of operators to vehicles and pullout and mid-block relief points). The planned operator assignments to runs are typically determined from the periodic “bid” process where operators select their work assignments from the schedule rosters (i.e., usually on the basis of seniority). However, there are ongoing adjustments needed for vacations and absences. Available ve- hicles and their locations are monitored as the basis for their assignments. There are various other complexities to garage operations that such software assists with, but these are not our primary subject. Not every agency uses this type of software, but if they do there are opportunities for integration with bus AVL systems. Rather than requiring the operator to log in to their run assign- ment directly on the MDT, the login can be with the operator number alone. The systems can send the operator number to the garage operations software, which can respond with the correct run assignment. This can reduce the chance to the op- erator logging into a valid yet incorrect run, which would re- sult in the route and schedule adherence monitoring being on an incorrect basis until this was noticed and the run assignment corrected. Paratransit Scheduling and Dispatch Software This type of software is used to support paratransit operations. Typically, it is used to enter individual trip bookings, create

99 run schedule manifests, enter trip completion data, and create invoices and reports. Integrating mobile data communications and MDTs with this software creates opportunities to further enhance operations. The systems can schedule same-day trip bookings using current vehicle locations and update vehicle manifests during the run. Trip completion data are retrieved from the vehicles in real time. Real-Time Traveler Information Systems A bus AVL system can use fleet schedule adherence and/or location data to develop real-time predictions for bus arrival times at stops. Agencies can use these predictions as an ad- ditional source of information for various types of customer information systems. DMS at selected stops, used to display predicted arrival times for the next bus(es), have been treated as an optional part of an AVL system for the purposes of this synthesis. However, agencies can add additional real-time traveler in- formation capabilities as an external system that is integrated with the AVL system. In particular, IVR telephone informa- tion systems and website applications can incorporate this pre- diction information. In these systems, the user needs to locate or navigate to the stop of interest to receive the predictions. In an IVR system, this involves using a sequence of voice-based menus (or a stop identification number shortcut) to retrieve spoken predictions, whereas in a website application the predictions can be shown once the user clicks on (or hovers the mouse over) the stop. With a website application, there is the additional option to display vehicle locations. Timekeeping and Payroll Although not essential, there can be integration with the agency timekeeping and payroll system. The system can pro- vide actual pull-out and pull-in times for runs as part of the basis for recording time worked and payroll for operators. Maintenance Management Bus AVL can be interfaced in various ways with a maintenance management system. The fundamental role of the mainte- nance management system is to schedule and track preventa- tive maintenance and repairs. A bus AVL system can use the mobile data communica- tions system to automatically provide current mileage data, in particular on a daily basis as the vehicle pulls in. The odome- ter interface to the VLU is typically not an adequate source for these data, because this interface just provides to the VLU to odometer pulses (i.e., mileage accumulated) since the login. The mileage source for the maintenance management system needs to be the overall accumulated mileage to date for the vehicle, which requires interface with an additional device for this purpose (e.g., a digital hub odometer). Such a device is sometimes also equipped to provide additional accumu- lated data of maintenance interest, such as operating hours or idling hours. Many recent vintage buses are equipped with electronic control modules for major vehicle subsystems, which can continuously record a wide variety of operating parameters (e.g., temperature and pressure). The challenge is to select which parameters to record for end-of-run collection and/or transmit in real time. This depends on the data available from the vehicle equipment, the capabilities of the maintenance management system, the storage capacity of the onboard sys- tem, and the transmission capacity of the mobile data com- munications system. Data Warehouse Software This generally refers to a relational database management and reporting system that supports the overall needs of an organi- zation, providing consolidated access to the databases of multiple software applications. Another advantage of a data warehouse can be that individual software applications can share information with multiple other applications, while only needing to be interfaced with the data warehouse. Geographic Information Systems (GIS) GIS allows for map display and for geographically oriented data to be displayed as additional layers on a map. The map display of fleet location and status is an integral part of a bus AVL system, and the agency GIS system is commonly the source of this map (allowing the agency to maintain only a sin- gle GIS map source). The system can expect its data (e.g., APC stop counts and maintenance data) for geographic visualiza- tion as part of the overall agency GIS. External Central Systems In addition to the other systems operated by the transit agency, the agency can establish additional interfaces to sup- port information sharing with other public agencies as well as with the private sector. The other public-sector agencies could include other regional transportation agencies (e.g., real-time travel speeds data as an indicator of current traffic conditions to the local traffic management authority and tran- sit information for 511 transportation telephone information systems). Private-sector collaboration is becoming of increasing interest for providing traveler information systems. In addi- tion to DMS, IVR, and website information services that might be made available directly by the transit agency, various

private-sector interests are emerging to use information that transit agencies release even more broadly available to the public. EMERGING TRENDS This section has highlighted several emerging trends whose importance is expected to continue to increase: • Agency-wide data warehousing is expected to become more prevalent and used with increasing effectiveness. The power of the underlying database management and reporting tools will continue to increase, and agencies will gain in both experience and expertise. These tech- nologies will enable an increasing use of “dashboards,” which are real-time graphical displays of key fleet per- formance indicators designed for quick comprehension at the executive management level. • Broadband mobile data communications is expected to become increasingly available, powerful, and cost- effective relative to radio-based mobile data communi- cations. Key drivers for this will be continuing advances in cellular data services and the emergence of mobile data services leveraging mobile WiMAX technology. The current generation of bus AVL systems has geared its capabilities to require real-time information exchange consistent with radio-based mobile data systems. As more agencies have broadband mobile data available, bus AVL systems will evolve to increasingly incorpo- rate features that take advantage of the new opportuni- ties for the real-time exchange of larger amounts of in- formation between the central and onboard systems. • Mobile access and location-based services will continue to increase in importance for traveler information ser- vices. Many customers can already use mobile personal devices to access telephone information systems and website applications. The number of customers with ac- 100 cess to such devices, and the experience and willingness to use them, should continue to increase. This should in turn make it more common for traveler information sys- tems to support and even focus on mobile access. A re- lated development is location-based services, as mobile devices increasingly incorporate relatively accurate real- time device location. This creates the opportunity for the traveler information to be customized to the current lo- cation. For example, a current research project is con- sidering technology that would allow a GPS-enabled cell phone to alert the traveler as they approach the stop where their trip itinerary would require them to alight the bus (S. Barbeau, Center for Urban Transportation Research, personal communication, Jan. 11, 2007). REFERENCES B1. Craig, W.C., “Zigbee: Wireless Control That Simply Works,” Zigbee Alliance, 2007 [Online]. Available: http:// www.zigbee.org/en/resources/whitepapers.asp [accessed June 11, 2007]. B2. PhoneScoop, 2007 [Online]. Available: http://www. phonescoop.com/glossary/term.php?gid=151 [accessed June 12, 2007]. B3. “Capacity, Coverage and Deployment Considerations for IEEE 802.11g,” Cisco Systems, 2007 [Online]. Avail- able: http://www.cisco.com/en/US/products/hw/wireless/ ps4570/products_white_paper09186a00801d61a3.shtml [accessed June 11, 2007]. B4. “What is WiMax Technology?” WiMax Forum, 2007 [Online]. Available:http://www.wimaxforum.org/ technology/faq/ [accessed June 12, 2007]. B5. Grey, D., Mobile WiMAX: A Performance and Compar- ative Summary, WiMax Forum, Sep. 2006, p. 3 [Online]. Available: http://www.wimaxforum.org/technology/ downloads/Mobile_WiMAX_Performance_and_ Comparative_Summary.pdf [accessed June 12, 2007].