FTA Real-Time Transit Information Assessment

Contract Number # DTFT60-99-D-41022/Order No. 00007

WHITE PAPER ON LITERATURE REVIEW OF REAL-TIME TRANSIT INFORMATION SYSTEMS

 

WHITE PAPER

LITERATURE SEARCH AND REVIEW
OF CURRENT PRACTICES IN PROVIDING
REAL-TIME TRANSIT INFORMATION

Final
AUGUST 2002

ACRONYMS

APTA                         American Public Transportation Association

APTS                         Advanced Public Transportation Systems

ATIS                          Advanced Traveler Information System

AVL                           Automatic Vehicle Location System

BART                         Bay Area Rail Transit

CCTV                        Closed-circuit Television

CTIS                          Central Traveler Information System

DMS                          Dynamic Message Sign

DGPS                         Differential GPS

ETD                           Electronic Train Destination

FTA                           Federal Transit Administration

GPS                           Global Positioning Satellite

ISP                             Information Service Providers

ITS                             Intelligent Transportation Systems

IVR                            Interactive Voice Response

LED                           Light-Emitting Diode

MMDI                        Metropolitan Model Deployment Initiative

MTA                          Metropolitan Transportation Authority

NYCT                        New York City Transit

PDA                           Personal Digital Assistant

PID                            Passenger Information Display

SNCF                        Société Nationale des Chemins de fer Français

TATS                         Traveler Advisory Telephone System

TOS                           Traffic Operations System

TRB                           Transportation Research Board

VIA                            Visualizzazione Informazioni Arrivi

WAP                          Wireless Application Protocol

WMATA                    Washington Metropolitan Area Transit Authority

WML                         Wireless Markup Language

1.0     INTRODUCTION

In May 2002, the Federal Transit Administration (FTA) initiated a project to develop a guidance document that would provide practical information to transit agencies and support them in fostering the deployment of real-time transit information systems (both bus and rail).  Figure 1 depicts the tasks involved in preparing this guidance document.  This document addresses the first task (literature search and review) depicted in Figure 1.1 below.

1.1       Purpose

The purpose of this white paper is to shed light on the successful implementation of real-time information systems in the United States and abroad.  Through a comprehensive literature review, this paper examines the implementation and operation of real-time information systems, as well as identifies the issues and problems associated with providing such information.

1.2             Background

Real-time transit information systems are key technology applications within the transit industry designed to provide better customer service by disseminating timely and accurate information.  Riders use this information to make various decisions about modes of travel, travel routes, and travel times.

Real-time transit information generally includes information on projected vehicle arrival and departure times, service disruptions and delays, transfers and other transportation services, as well as other related information such as date and time, weather, public announcements, security related information and updates during terrorist/emergency events, and other general events in the local area.  This information is provided to assist riders in making pre-trip and en route (including in-vehicle) trip decisions.  Moreover, the provision of real-time transit information helps improve the visibility of transit agencies within their communities.  Access to this information is made through a variety of media including dynamic message signs (DMS) at stops and stations, kiosks (at bus shelters, office buildings, shopping centers, and other locations), cable television, personal digital assistants (PDAs), the Internet, and telephones.  There are currently 16 transit agencies that have operational multimodal traveler information systems and 25 transit agencies that have planned multimodal traveler information systems as reported in the areas outside of the 78 largest U.S. metropolitan areas (Table 1-14 of the APTS Deployment Year 2000 Update, May 2002).

The availability of real-time transit information helps travelers make efficient use of their time by allowing them to pursue other activities while waiting for a bus or train.  It also has been shown to help reduce anxiety by letting travelers know when the next bus or train will arrive or depart.

Automatic vehicle location (AVL) systems usually provide real-time transit information.  The most common type of AVL is global positioning system (GPS)-based.  A GPS-based system provides very accurate data on the location of transit vehicles.  Through the calculation of reference data from at least four GPS satellites, a vehicle’s location (longitude and latitude) can be calculated to within 10 to 20 feet.  This accuracy can be improved by using differential GPS (DGPS), which uses a reference station in addition to the GPS satellite data to determine location.  In any case, accuracy in vehicle location is critical in providing reliable real-time transit information.  In fact, it is a key factor in the success of any such system.

The method of predicting real-time arrival times in below-ground rail applications consists of determining the location of the rail vehicle within a specific signal block, and using the speed of the rail vehicle and distance to the next station (located within a specific signal block), and calculating the time it will take for the rail vehicle to reach the next station.  Downstream station calculations are accomplished at the same time, using the rail vehicle's speed and distance to each stop.  Above-ground rail vehicles, just like buses, often use GPS as the method of determining vehicle location, and then calculate arrival times the same way they are calculated for below-ground vehicles.

Another element in the success of a real-time system is the accuracy of algorithms used to predict bus arrival time.  Accurate prediction of arrival times has not always been possible because of the number of variables involved (e.g., traffic flow and speed).  However, in recent years, more sophisticated techniques and algorithms have been developed and successfully tested, providing reasonably accurate and reliable predictions.

Given that accurate vehicle location and arrival time prediction are now possible, why haven’t more transit agencies across the United States deployed such systems?  Possible reasons include:

• Costs of infrastructure investments
• Institutional issues
• Liability and the loss of integrity associated with providing inaccurate or unreliable information.

2.0     APPROACH

To ensure a consistent approach to the review and evaluation of relevant documents and articles, a literature review template (Appendix A) was developed.  The template focuses on reviewing methods and techniques used by agencies in the United States, Europe, and Asia to successfully deploy real-time transit information systems; identifying and describing the issues and problems associated with implementing and operating these systems; examining current data collection, fusion, and dissemination techniques and methods; examining advanced traveler information system (ATIS) infrastructures and business models; and using the National ITS Architecture and standards for deployment.

Documents and articles published within the last five years dealing with real-time transit information systems were reviewed for this white paper.  Appendix B lists all the sources and documents that have been reviewed.  Sources for these documents include the proceedings of intelligent transportation systems (ITS) world congresses, ITS America conferences, American Public Transportation Association (APTA) bus conferences, Transportation Research Board (TRB) annual meetings, the APTA Rail Transit Conference, the TRB/APTA Light Rail Conference, and APTS publications.  A complete listing of references is in Appendix C.  Once the literature review was completed, the information from the review templates was synthesized into this white paper.

3.0     LITERATURE FINDINGS

The results of the literature search are presented around the nine (9) major questions in the literature review template (Appendix A).  The information collected in this literature review focuses on the types of real-time information provided, the types of media used for disseminating real-time information, and the issues associated with implementing and operating real-time information systems.  Most real-time transit information systems use GPS-based AVL systems.  Generally, the only information disseminated to passengers is vehicle arrival time, location, or departure time.  Most real-time transit information systems have been implemented in relatively large urban transit systems.

Despite a lack of in-depth analysis in the literature, it is clear that transit users overwhelming appreciate and use real-time transit information.  Systems like London’s COUNTDOWN, Belgium’s PHOEBUS, and Portland, Oregon, Tri-County Metropolitan Transportation District’s Transit Tracker received 90% or higher satisfaction ratings from users.  Similarly, in Sweden, after implementing the “Think Tram-Use Buses” project, which provided real-time arrival times at bus stops and signal priority, market share for public transport jumped from 19% to 22%.  In addition to relieving passengers’ anxiety while waiting at transit stops, providing real-time arrival information was also a factor in making them feel safer while waiting at stops.

Two areas did not receive much attention in the literature despite their significance in implementing real-time transit information systems.  The first is the use of the National ITS Architecture and standards, and the other is organizational and institutional involvement.  Adoption and conformity to the National ITS Architecture should be part of any ITS project to ensure interoperability within and across transportation modes.

To involve the private sector, mainly information service providers (ISPs), it is important to educate ISPs about the business opportunities inherent in such projects.  Although recent surveys and studies indicate that the public is willing to pay for real-time information, a large number of ISPs have been reluctant to be part of ATIS systems.  This is because ISPs are not convinced of the business opportunities and believe that the ATIS services market will not mature for at least three to four years because of market uncertainty.  Consequently, private sector companies believe that consumers may not be willing to pay for real-time information and the ISP’s may need more evidence and education before they are willing to invest in ATIS systems.

It was also noted in the literature that strong project management is critical for the successful deployment of a real-time information system.  Some agencies failed to develop alternative plans to deal with problems during implementation.  For example, TravInfo® relied on the “best-case” scenario for design and implementation instead of also considering the “worst-case” scenario (see Section 3.3.1).  As a result, when Caltrans’ Traffic Operations System (TOS) project, which was to provide data to TravInfo®, was delayed and then reduced in scope, it severely impacted the ability of TravInfo® to receive accurate and reliable data. 

Finally, understanding the complexity of real-time information projects and their requirements in terms of resources and time is critical.  Some agencies underestimated how long a project will take from start to finish.  As a result, implementation of the real-time information system suffered.

3.1       Types of Real-Time Information Provided

According to the literature, real-time transit information systems provide the following types of information:

• Estimated arrival or departure time for, or “countdown” to, the next vehicles
• Vehicle location
• General information on service area, fares, routes, and travel times
• Service disruption/delay information
• Information on transfers and other local/regional transportation services
• Other real-time information, such as date, time, and weather
• Peripheral information, such as advertisements.

Each of these types of information serves a particular function within the spectrum of transit information, such as pre-trip or en route information.  It is noteworthy that 21 out of a total of 53 documents reviewed included real-time information systems that provide estimated arrival/departure times of transit vehicles.  The second most discussed systems (12 documents) were those that provide transit vehicle location display.  Appendix D lists all the transit agencies included in this white paper and Appendix E lists agencies that dealt with real-time systems.

3.2       Types of Media for Disseminating Real-Time Transit Information

The types of media that are of interest in the literature include those listed below.  These media have been designated either interactive and non-interactive.

Interactive devices (such as kiosks and the Internet) allow users to get exactly the information they are seeking in a very short time.  Z. R. Peng and R. Huang [18] state that “interactive communication provides user interactivity and feedback channel.  Users can actively manipulate and search for specific information based on their own needs and give feedback to the system providers.”  By tracking pages visited, number of hits, and periods and locations of heavy use, system providers will be able to better maintain the system and to improve upon it.

The two types of media that were dealt with the most in the literature were DMS and the Internet, respectively.  Fifteen documents discussed DMS systems, while twelve discussed the Internet.  Interactive kiosks and WAP-enabled mobile phones tied for third place with six documents addressing each.  This should not be construed as an indicator of actual deployment ratios.  The number of documents found in the literature is mentioned simply to point out that most research and papers are focusing on the Internet and DMS.  Hence, more extensive evaluations of the other types of media may be required in the future to arrive at a better understanding of these systems.

Z. R. Peng and O. Jan [6] evaluated dissemination media for real-time transit information (such as pagers, the Internet, and PDAs) against a set of seven criteria.  For each media type, they provided a general description, along with its advantages and limitations.  Each medium was evaluated in terms of accessibility, versatility and interactivity, information-carrying capacity, user friendliness, cost to install, cost to use, and ease of implementation.  The Internet and kiosks were found to be the best media overall, based on these seven criteria.  DMS and closed-circuit television (CCTV) were considered good dissemination media because of their modest cost and flexibility in the variety of information they can provide.  PDAs and automated voice annunciators were promising technologies for real-time transit information systems, but were not ready for implementation when the paper was published (1999).

3.2.1        Internet

Several Internet-based projects were described in the literature.  One of these is TravInfo®.  The goal of TravInfo® is to broadly disseminate accurate, comprehensive, timely, and reliable information on traffic conditions and multi-modal travel options to the public in the San Francisco Bay Area.  About 30 ISP firms joined the TravInfo® project because they were interested in deploying traveler information through various media, including Web pages and Internet-based personalized profiling and alerting services [22].  Perhaps the most significant attribute of the TravInfo® field test was the creation of partnerships among public and private parties.  The project helped foster constructive relationships among the three principal public agencies, and the benefits carried over into other joint ventures.  Many of the TravInfo® private participants went on to form alliances with one another, and their positive experience with TravInfo® led them to take part in other field operational tests and model deployment initiatives around the United States.

As part of the Smart Trek Metropolitan Model Deployment Initiative (MMDI) in the Seattle, Washington area, two new applications were created to provide real-time transit information [9].  Two types of media were used to relay the information to the transit passengers:  (1) on the Internet and (2) at the transit center.  Busview is an Internet application that displays the real-time location of all the transit vehicles operated by King County Metro, the regional transit system.  Transit Watch is a real-time arrival prediction system suitable for deployment in transit centers.  Busview and Transit Watch are designed to operate over the Internet and are sufficiently general that they can be used easily in other cities interested in implementing real-time transit information.

Busview Plus uses a Java applet to display real-time transit vehicle locations on a variety of computing and operating system platforms.  Busview Plus is platform-independent, with the goal of making transit vehicle location information accessible to anyone on the Internet.  An additional goal is to develop an interactive interface that promotes modal change and encourages the use of transit.

The Transit Watch project deployed an Advanced Public Transportation System (APTS) /ATIS that predicts the arrival status of transit vehicles.  This prediction results in one of four states:  (1) On Time, (2) Delayed “n” Minutes, (3) Departed, and (4) No Information.  The goal of the project was to develop an interface that promotes the use of transit by reducing the stress inherent in transfers.  This project leverages the ITS Backbone component of the SmartTrek MMDI project[1].  This project was originally designed to be deployed at three transit centers, but it has since been made available on the Internet as well [9].

Stuart Maclean and Daniel Dailey discussed the dissemination of real-time transit information to a WAP cellular phone [16, 17].  The use of WAP phones was an extension of the ongoing Internet-based MyBus program in Seattle, Washington.  Maclean and Dailey discuss the challenges, such as limited display area and capability, of using WAP phones for real-time information.  To compensate for the phone’s physical restrictions, MyBus maximized its use of the screen by combining information, such as scheduled arrival time and departure status, into one data field.  By January 2001, the MyBus WAP site had had over 9,000 hits since its initial release in September 2000.  Future work for this project includes formatting bus arrival data for PDAs.

3.2.2        Dynamic Message Signs

DMSs at bus stops and stations are used mainly to provide arrival or departure information.  The primary purpose of bus stop and station displays is to reassure the customer that s/he is waiting for the right vehicle in the right place and to inform him/her about the time the vehicle will arrive, which allows the customer to exploit the time until vehicle arrival.  In many cases, bus stop and station displays also are used to provide static information about the transit service and to display advertisements.

DMSs use liquid crystal display, yellow or red light-emitting diode (LED), or video display technologies to provide information.  According to INFOPOLIS [50], the VIA system (Visualizzazione Informazioni Arrivi) in Turin, Italy, installed a red LED display, one of the first DMSs installed in a public transit system.  DMSs using red LED signs are used in London as part of its COUNTDOWN system.  In some cases, “thermometer” displays are used to present the waiting time and/or the location of a public transit vehicle. 

COUNTDOWN (Figure 3.1) shows the next (one to four) buses expected to arrive at every equipped bus stop, as well as the time to bus arrival in minutes.  If the stop serves more than four bus routes, the buses beyond the fourth appear on the display on a scrolling basis.  Periodically, the last line is used as a “message board” to provide additional transit information, such as delays, transit passes, and other transit related information entered from the operational center.

Figure 3.1:  London Bus COUNTDOWN Sign

The Los Angeles Metropolitan Transportation Authority (MTA) implemented real-time bus arrival information for its Metro Rapid Bus program [12].  In addition to real-time transit information, MTA is also using the AVL systems for transit signal priority.  Bus arrival and delay information is displayed at bus stops using LED signs (see Figure 3.2).  According to Kang Hu and Chun Wong [12], the real-time information system has been very popular with bus riders, and the LED signs are esthetically pleasing.

Figure 3.2:  Los Angeles Metro Rapid Real-Time Arrival Sign

3.2.3        Interactive Voice Response

IVR telephone information systems allow customers to call a single phone number and navigate a menu for needed information.  Previously, transit customer service operations relied on agents to provide various types of information over the telephone.  For many years, automated telephone information systems assisted agents in answering routine questions.  The new systems eliminate the need for agent involvement in many information requests [1].  One problem with IVR systems is that they do not always have good voice recognition.  However, speech recognition technology has improved recently.  Another difficulty noted in the literature is that some systems incorporate automated distribution features for information that would be too time-consuming to provide over the telephone.  In these cases, information can be sent via fax or e-mail [1].

The Bay Area’s TravInfo® project uses an IVR system.  The primary means of public access to TravInfo® information is via the Traveler Advisory Telephone System (TATS).  TATS uses a telephone’s numeric keypad as the interface for callers to obtain TravInfo® information from a menu-driven system.  The current TATS service has a series of menu options for callers to retrieve traffic or transit information.  According to Youngbin Yim, et al [28], one possible improvement is to provide a personalized access service tailored to individual customer needs.  Personalized information access would reduce retrieval time and enhance ease of use.  TATS callers could input a persona1 identification number, and the system would give them a traffic report on routes they had pre-chosen (e.g., US 101, the Bay Bridge, and I-580).

3.2.4    Interactive Kiosks

Kiosks can be located in a variety of places, including near public transit, in stations, at stops, or in other high foot-traffic locations (e.g., in shopping malls).  They can also be located at places with high concentrations of people, such as public buildings and tourist locations.  The literature suggests that information available via kiosks usually includes:

• Travel information, such as optimum route, itineraries, and arrival times at specific locations
• General information about various activities in the city or metropolitan area covered by the system.

Kiosk functions vary considerably.  Multi-modal information, such as information about public and private transportation, can be offered; or kiosks can provide information about only public transit modes and services.  Similarly, some kiosks provide only off-line information, such as static schedules, whereas others also have real-time information or access to internet web sites.  Finally, in some cases, ticketing facilities are also present at the kiosk.

While a large number of the existing kiosks are stand-alone units with their own databases that are updated on a periodic basis, others are connected to databases that are located at a central facility and updated centrally.

Most kiosks use color screens with or without touch screen capability.  The latter is quite familiar because it is often used in other industries, such as the banking industry (e.g., automatic teller machines) and, thus, is better understood by users.  The literature discusses the “man/machine interface,” since it is directly related to the usability of a kiosk.  Some new ideas regarding the user interface (e.g. simplicity of the user interface; provision of useful and understandable answers; right location; and right housing) have been implemented in systems such as the German RIA[2] – HAFAS[3] and the French Société Nationale des Chemins de fer Français (SNCF)[4] terminal [50].

Several functional characteristics of kiosks that were discussed in the literature should be taken into account when a kiosk is being considered.  These characteristics include:

• Simplicity of the user interface
• Provision of useful and understandable answers to the user request
• Effective location
• Appropriate housing
• Efficient maintenance
• Use of standards.

According to the literature, kiosk users mainly have problems with the touch keys and/or the touch screen, as well as with the time required to wait until they get the system response.  However, the general level of satisfaction is rather good.  Of course, level of satisfaction is a purely subjective measure and can change with time and with technological advances, as well as with social behavior.

Advanced Public Transportation Systems:  The State of the Art Update 2000 [1] explains that a few transportation agencies have placed kiosks at public sites to provide transit information to travelers who might not be aware of transit alternatives.  In addition, public-private partnerships are being formed to explore the commercial viability of kiosk networks.  Advertising on the exteriors of kiosks is one approach that was described in the literature.  Advertising on the various content pages of the system is another.  However, as much as kiosks seem a lucrative choice, they do have several drawbacks.  Kiosks usually have high capital, maintenance, and operating costs.  And while the Internet provides transit users with information 24 hours a day, seven days a week, some kiosks have restricted access, such as those located in shopping areas.  Additionally, normally only a few kiosks are available in a transit service area.  Kiosks installed in various public locations are often far away from other transit agency facilities.  This can make it difficult to provide routine maintenance and repair.  Operational solutions to these problems include remote device monitoring tools and custom keyboards or touch screens.  Maintenance solutions include collaborative local support arrangements with host sites.

3.2.5    Video Monitors

According to Advanced Public Transportation Systems:  The State of the Art Update 2000 [1], video monitors are often used when a large amount of information needs to be displayed and where flexibility in using graphics, fonts, and color is needed.  Since the character height needs to be relatively small, video monitors are best suited to locations where transit users can stand relatively close to the monitor.  For example, a video monitor is well suited for a display at the entrance of a station indicating the location of the berth for buses serving specific routes (see Figure 3.3).  A video monitor providing real-time arrival updates would be less suited to a central display near a group of bus berths, since transit users might be uncomfortable moving away from the berth and losing their places in line to get close enough to read the display. 

The challenge to implementing video monitors or DMS remains the issue of getting information to the device.  Wireline placement can be difficult and costly.  According to the literature, wireless transmission of information has not yet proven to be consistent enough to handle large amounts of data.

Z. R. Peng and O. Jan discuss another type of video monitoring¾closed-circuit television.  According to them [6], both the Ann Arbor Transportation Authority and New York MTA have tested their own systems.  The Ann Arbor Transportation Authority tested its in-terminal passenger information system using two video monitors located at the downtown transit center.  The monitors display bus arrival and departure information, as well as possible delays.  MTA mounted 100 video monitors at major bus stops.  The monitors display transfer points to other bus routes or subway lines.  Peng and Jan contend that the “drawbacks of closed-circuit televisions are that they are available in limited places, such as major transit centers, and they cannot provide users with interactive operations, such as query and search.”

Figure 3.3:  River Valley Transit (Williamsport, Pennsylvania) Bus Bay Information

3.2.6    Personal Digital Assistants

According to the literature, hand-held PDAs only recently appeared as information media in the transit field.  These devices are very small, entirely autonomous, and portable.  The traveler can consult them at any moment anywhere.  PDAs can be used to obtain pre-trip and en route information.  Advanced Public Transportation Systems:  The State of the Art Update 2000 [1] claims that one issue with PDAs is the reluctance of customers to pay for traveler information via pagers or handheld computers.  However, private sector companies are devising ways to provide more “value added information,” such as personalizing information on a traveler’s commute by informing him/her when transit delays are occurring.

Another disadvantage of PDAs such as pagers, according to Peng and Jan [6], is that “pagers can deliver only limited information; limited numeric and text information can be displayed on the small pager, and no audio information can be delivered.  Furthermore, the communication is one way.  That is, it is impossible for users to actively inquire about information.”

3.2.7    Fax

Of the documents reviewed, only the Washington Metropolitan Transit Authority (WMATA) was listed as using a fax service through its TripFax system.  However, TripFax does not provide real-time information.  Instead, the fax service is used to fax static itinerary plans.

3.2.8    Non-interactive Kiosks

No information on non-interactive kiosks was found in the published literature.

3.2.9    Telephones (voice information)

No information on telephones was found in the published literature.

3.2.10  Mobile Telephones (data using WAP)

Mobile telephones only recently appeared as media for providing real-time information.  These are very small, entirely autonomous, and portable.  The traveler can consult them at any moment and anywhere.  They can be used for obtaining pre-trip, as well as en route, information.  Most of these phones use LCD screens for displays and keyboards, and pencils or buttons are used as input interfaces.

3.2.11  Cable Television

In California, cable television is being utilized for transit information dissemination in the Orange County Smart Traveler system.  An AVL system is used to monitor bus locations and provide real-time data to the Central Traveler Information System (CTIS).  Other data providers are the City of Anaheim and Caltrans.  CTIS integrates all of the real-time traffic and transit information and distributes the information to each agency.  Orange County Transportation Authority is disseminating the information via three kiosks, cable television, and the Internet [13].

3.3       Issues, Problems, and Solutions in Implementing Real-Time Transit Information Systems

Issues, problems and solutions related to real-time information systems received a considerable amount of coverage in the literature reviewed.  Several common themes were observed in the documents.  Project management is an essential component of successful deployment of a real-time information system, or any other system for that matter.  Considering risk management in the planning stages helps in getting the system designed and implemented with minimal delays.  As mentioned earlier, had TravInfo® considered risk management or made contingency plans in its planning stage, it could have better dealt with the data problems it encountered.  There are always many unknowns when deploying any system, especially new technologies such as real-time information systems.  Therefore, considering risk management and making contingency plans becomes an essential component of project planning and management.  Some of the literature discussed the importance of not underestimating how long a project will take from start to finish, while other documents stressed the importance of good marketing to promote the system.

Also, comprehensive and sound data management techniques are key to the success of a real-time information system.  When data are not managed properly, it not only can degrade the accuracy and reliability of the real-time data, but also can slow the whole system down to the point where it will not be real time anymore.  For example, data from loop sensors and Freeway Service Patrol that were fed into TravInfo® didn’t provide sufficient geographic data coverage or accuracy.  Hence, the most significant source of data soon became the incident reports of the computer-aided dispatch system from the California Highway Patrol, which required significant interpretation and data entry into the Traveler Information Center’s system.  During the field test, it took an average of 10 to 11 minutes to process an incident from the Highway Patrol’s computer-aided dispatch system and enter it into the Traveler Advisory Telephone System [22].

3.3.1    Planning

Two different system-planning issues were discussed in the literature.  In the case of TravInfo® [22], the project relied on a best-case scenario for both system design and implementation.  That is, it assumed that Caltrans’ TOS, which was still to be implemented and was to provide data to TravInfo®, would be available on schedule and to the original specifications.  It did not consider worst-case scenarios to develop possible alternative courses of action.  Such risk assessment strategies and contingency planning are vital to moderate the potentially negative consequences of unforeseen events.  Therefore, when Caltrans’ TOS implementation was significantly delayed and its scope was reduced, the future of TravInfo® was in doubt. 

Other shortcomings of the TravInfo® project mentioned in the literature included:

• Underestimating the extensive time required to develop mutual understanding and trust among project partners, who all had varying objectives
• Underestimating the uncertainty of the consumer market for commercialization of traveler information products and services
• Having inadequate information about how to assign a consumer value to the information being provided
• Not defining appropriate roles for the parties involved
• Not appreciating the importance of having enough time and funds to market the product and convince people to use it.

The literature suggested that TravInfo® should have:

• Allowed more time for start-up tasks and pre-planning, including administrative procedures and task management plans.
• Developed a risk-management plan early in the planning process to deal with unforeseen challenges and to ensure consultants’ compliance with project specifications.  As was common in many field tests, TravInfo® had to cope with numerous unforeseen obstacles that could have been mitigated if a risk-management plan had been developed early in the planning process.
• In the pre-planning phase, legal and institutional mechanisms could have been identified to give agencies more leverage in ensuring that contractors’ and consultants’ work complied with project specifications.

Another issue discussed in the literature in terms of planning is more technical.  In the case of Busview and Transit Watch, Seattle’s Metro Transit had a proprietary AVL system.  As a result, Metro Transit couldn’t directly interface with the AVL system to obtain needed data for its real-time information system.  Hence, the use of the AVL data became more complicated and could have been simplified if it were an open system [31].  Better planning for the acquisition of the AVL system (i.e., not accepting a proprietary system or negotiating better accessibility to the proprietary data) would have eliminated this problem.

The city of Helsinki ran into another problem ¾ liability.  The implementation and operation of its real-time passenger information system encountered technical problems involving the establishment of reliable communications between the central management system and the information displays at the bus stops.  In solving these communications problems, additional problems were caused by disagreements about the liability and responsibility regarding the communications.  The city of Helsinki had two separate contracts with two vendors (one for the management system and one for the bus stops) [14].  Having two separate contracts compounded the issue because each vendor was claiming that the communication problems were the fault, and hence the responsibility, of the other.

3.3.2    Implementation

In the case of the TravInfo® project, while productive at some levels, the project approach during the field test was not flexible enough to quickly respond to problems that arose unexpectedly.  These problems included delays in the development of the Caltrans’ TOS and, eventually, in the delivery of a system that was not fully compliant with design specifications [22].  As previously stated, this resulted in the degradation of the accuracy and reliability of the data TravInfo® was receiving.

Another issue that TravInfo® faced was its dependence on a Caltrans project to build a TOS on part of the Bay Area freeway network using inductive loop detectors.  Because of an event over which TravInfo® had no control (related to the awarding of contracts), the TOS project was significantly delayed and then ultimately reduced in scope.  The result was inadequate TOS data coverage in providing speed and congestion data.  Although Caltrans made a concerted effort to improve the quality of existing loop detectors and TravInfo® management initiated new projects to acquire additional data sources during the field operational test, the data provided by the TOS were not able to sufficiently support TravInfo® either in extent of coverage, accuracy, or reliability [23].

In the case of the Skybus system in Copenhagen [30], the most important issue was the lack of project management skills.  The focus was on the technical portion of the project, and consequently important details were missed in the management of the project.

3.3.3    Marketing

Lessons learned from TravInfo® [22] encourage conducting organized consumer research for a better understanding of the local market and implementing aggressive marketing strategies to increase public awareness of TravInfo® and its privately offered products (31).

The literature about Copenhagen’s Skybus [30] emphasizes that good marketing is required for the success of a real-time information system.  It is through marketing that transit agencies can get more passengers to recognize and use the new technology and, in the process, increase their ridership.

3.3.4    Operations

One major operational problem with London’s COUNTDOWN AVL system [51] was that bus drivers were not registering their vehicles into the system properly.  Not registering a vehicle meant that critical “next bus” information was not computed and displayed to the public.  Not registering vehicles presented a major challenge to the perceived accuracy of COUNTDOWN, with up to 15% of vehicles not showing on the signs as of late 2000.  Several developments that were considered to enhance COUNTDOWN included:

• Linking each bus radio to the on-board electronic ticket machine to assist driver log-in,[5]
• Evaluating the integrated services digital network for landline communication to and from the stops
• Developing initiatives to allow third-party dissemination of COUNTDOWN information.

While it is relatively easy to make changes to the database of timetables and lists of buses in service to ensure that a system has up-to-date data, other factors such as bad entries on bus routes by operators can have an overall effect; and the system can’t provide accurate and reliable bus arrival/departure information.  This has been a major problem with the Timechecker system.  Similar to COUNTDOWN, the Timechecker system in Liverpool provides real-time transit information at bus stops.  However, each morning the bus operator must enter the fleet number and running board for his/her bus into the system, otherwise the system does not know what buses are on the route.  It has not always been possible to obtain the manpower to do this, which has, at times, had a detrimental effect on the reliability of the system.  Hence, internal education of staff and operators on the system is essential.

3.3.5    Maintenance

As with any system designed for customer service and/or convenience, “up time” is absolutely critical.  If customers are frequently denied service because a system is “down,” they will soon stop trying to use the system all together.  The experience of Skybus [30] confirms that a good service agreement is necessary for the successful operation of a real-time information system and for maintaining its data reliability and integrity.

3.3.6    Other Issues

Just like any major capital expenditure at any transit agency, the implementation of ITS systems, including real-time transit information, usually includes involvement at all levels of the organization, including the highest level.  Working with congressional staff to secure the required federal funding, as well as allocating matching local funds, requires the approval and cooperation of the senior staff, general managers, and, in most cases, the board of directors.  Hence, the “organizational” role is very critical in deploying real-time transit information systems.  It is thus very unfortunate that, of the 50 documents reviewed, none discussed or investigated this area.

The only document that touched on one aspect of institutional issues is the United Kingdom’s Real-Time Information Group:  A National Strategy [35].  The authors in this document advise against using real-time data negatively to monitor when bus drivers are running late, for example.  Instead, real-time data should be used positively to deliver better service.

3.4       Techniques for Data Collection, Fusion, and Dissemination

Data collection, fusion, and dissemination were addressed in a large number of the documents reviewed.  Although data collection and dissemination were not dealt with at a significant level or depth, they were discussed in relation to their role in supporting different devices and outlets.  If there is one common component to the various systems and dissemination media reviewed, it is that the most common source for bus or train location was obtained through an AVL system.  Although an AVL system is the best option for location information, it could nevertheless be a hurdle in the deployment of a real-time information system if it is a proprietary system.  For example, as stated earlier, the Busview system couldn’t get AVL data easily because it was proprietary system.

The previously-mentioned document, “Real Time Information Group:  A National Strategy” [35], makes the following recommendations regarding real-time information data:

• Establishment of a common data format, independent of the means of transmission
• Establishment of a common means of transferring data between different systems on and off the vehicle
• Insurance of the security of data.

The literature that addressed the data aspect of real-time systems can be divided into three groups in terms of media used for dissemination:  1) documents that dealt with WAP;
2) documents that addressed DMS and/or the Internet; and 3) documents that dealt with a number of different media, such as non-interactive kiosks, PDAs, IVR via telephone, video monitors, interactive kiosks, DMSs, faxes, and cable television.

3.4.1    Using Wireless Application Protocol

Two documents [17, 32] addressed the data aspect of a WAP system.  The first document [17] discusses the King County Metro system, which delivers content to Internet-enabled mobile devices such as cell phones.  The information provided includes arrival and departure information at time points along the route.  The mechanism for downloading data to a mobile device involves the user logging on to the system using the Internet and downloading the data from the appropriate Web page to the device.

However, due to user interface restrictions, a mobile device cannot yet be used to surf the Web in the same way as a desktop computer.  Thus, a wireless markup language (WML) has been introduced as the new language for WAP-delivered content.  The WML standard ensures that content developers can expect a minimum level of functionality on any conforming mobile device.  The advantage of this approach is that it allows for the development of standards for these devices, which in turn result in efficiency, economies of scale, and national interoperability.

According to Maclean and Dailey [17], a major problem to overcome is the delivery of necessary bus departure information to a device with the following physical restrictions:

• A display area supporting 12 fixed characters per row of text and up to four rows.  One row may be reserved for function key labels.
• Support for ASCII text.
• Horizontal and vertical scrolling.
• Choice selection via arrow or numeric keys.
• Two programmable function keys.

William Hickox [33] discussed the Rhein-Main-Transport Association, which is responsible for the regional public transport system in the Rhein-Main-Area in Germany.  The Rhein-Main-Transport Association operates a system that utilizes WAP-enabled mobile telephones.  In the city of Hofheim, a communication network between the local bus companies, the regional bus companies, and the German Railway was established.  The real-time data on vehicle location for the various companies are transmitted to a local server in Hofheim, where schedule data are also present.  This centralized setup allows for a better synergy of real-time information systems of the various modes.  Real-time information is then disseminated to the users via applications like the Internet or to mobile-radio providers (see Figure 3.4).

Figure 3.4:  Rhein-Main-Area (Germany) System[6]

3.4.2    Using Dynamic Message Signs and/or the Internet

TravInfo®:  According to the evaluation study of the TravInfo® Regional Transportation Information System [22], “two sources of data were fed automatically into TravInfo® database:  data from the inductive loop sensors of Caltrans’ TOS and data from the Freeway Service Patrol.  However, these sources did not provide sufficient geographic data coverage or accuracy.  As a result, the most significant source of data soon became incident reports of the computer-aided dispatch system from the California Highway Patrol, which require significant interpretation, data entry into the Traveler Information Center’s system, and follow-up by the operators.  Relying on operators to perform TravInfo® tasks proved time-consuming, especially in the transfer of incident data from the Computer-Aided Dispatch system’s terminal to the center’s system, and from the center’s system to the telephone advisory system.”

The use by TravInfo® of a centralized regional database was a step forward in solving this problem.  Not only does it make sense in terms of providing synergy with other ATIS systems in the region, but it was also welcomed by the ISPs.  The ISPs believe that a centralized database helps to expedite the transfer and exchange of data among various entities.  In addition they believed that it provides a level playing field for commercial developers.

Busview:  “BusView displays the current location of a bus on a map.  A transit user selects a geographical area such as their home or workplace.  If the default area does not meet their needs, the user can easily scroll the map in any direction to display another area.  They can also specify routes they are not interested in and look at two areas simultaneously.  Clicking an icon also allows them to jump to the published timetable or to bring up a new bus progress screen.  Holding the cursor over an arrow icon shows the user either the time point's intersection or name of a major landmark if the time point is a location, such as a shopping mall.  Bus icons below the route indicate the route number the bus is traveling and its location and the time its position was last calculated.  By simply clicking anywhere on the route in the bus progress window, a user can add an alarm clock icon that will produce a visual and audible notification when the next bus passes that particular point.  This can provide an alert to the passenger that it is time to leave to catch the bus” [1].

Skybus project:  The technical solution chosen for Skybus is based on positioning with DGPS.  A bus computer is the basic unit in each bus and contains all the planned data for that vehicle.  These data include the vehicle’s schedule, the geographic information, and information about the names of the stops.  The complete line and all stops are measured with GIS equipment.  In the bus, the tracker software registers all events:  when the bus starts, when it gets near a bus stop, when the doors open and close, and other events.  When the driver starts the bus, s/he logs on to the specific trip s/he is going to make.  On the basis of all the registrations in the tracker software, the bus computer knows each stop and which stop is next.  This information goes to the passengers on the passenger information display (PID) inside the bus and to the driver on the driver’s display.  Furthermore, the bus computer knows whether the bus is on schedule or not.  This information goes to the driver on his/her display as a +/- time so s/he will know all the time whether s/he is ahead of schedule or late.

Delaware Transit Corporation (DTC):  One of the unique things about DTC’s service is that it does not operate on set timetables, but rather a majority of the service operates on a headway range.  For example, service from the Boardwalk to the Park-n-Ride operates every 10 to 30 minutes; and, thus, the customers do not know if they just missed a bus or if it is a couple of minutes away.  Therefore, a solution was needed that could provide real-time passenger information when there were no scheduled time points.

DTC reviewed the technology available in the industry; and, while several vendors were able to provide a solution based on schedule adherence, they could not address headway range schedules.  In the spring of 2000, DTC was first introduced to the idea of predictive arrival systems.  A predictive arrival system calculates expected arrivals based on history rather than adherence to schedule.  A database of experience was developed over months.  This database was used to create the decision-making process of the predictive algorithm.  Once the initial data were collected, the system became operational on the weekend of July 4, 2000.  Tests were continually conducted to check the accuracy of the prediction system.  Within a week, the degree of accuracy was plus or minus 30 seconds” [33].

The RAPID system [29]:  Most prediction systems rely on historical data.  Rather than a broad-based approach, Saab’s RAPID system provides an initial estimate close to the eventual arrival time by making use of recent performance data for services experiencing the same road conditions.  Once the bus has started its journey, the prediction system is able to compare how the bus is progressing based on the initial prediction.  Updates to the predicted times are then transmitted to the appropriate information message signs.

Bay Area Rapid Transit (BART) [1]:  Electronic train destination (ETD) signs are located at all 39 BART stations providing estimated time of arrival.  Once the train doors close, arrival times are calculated for the station’s next three or four trains.  Train location data are then integrated with speed, scheduling, and other vehicle information to predict future arrivals at the downstream station platforms.  This prediction information is then displayed on the ETD signs at each downstream station.

Blacksburg Transit in Blacksburg, Virginia:  In this system, a polling strategy is used to receive location information from individual vehicles.  The base station transmits a code for a particular vehicle and, in turn, only the polled vehicle sends back data.  In this manner, the base station polls all 36 vehicles in the fleet and updates their individual location data.  The computer at the base station performs multiple tasks as a data processor, Internet server, and telephone answering machine.  The raw location data received are then manipulated to produce time of arrival information using a predictive algorithm.  To transmit an estimated time of arrival signal to the bus stop receivers, an FM subcarrier system is used.  This is done by first sending the desired information packet to the local FM radio station through a telephone line.  A modem at the radio station decodes this message and provides it to the FM-subcarrier generator.  The receivers at bus stops pick up this signal and retrieve the relevant information by looking at the header field of the packet.  Arrival time information is then displayed on the dynamic message display at the bus stop [11].

3.5       Transit ATIS Infrastructure and Business Models

Two studies [3, 15] discussed in the literature evaluated the public’s willingness to pay for real-time transit information.  Both studies showed that a majority of passengers would be willing to pay for real-time transit information if they found it to be valuable.  Results of the San Francisco Bay Area survey conducted in 1999 revealed that, of those who said they get traffic or transit reports from various sources, 17% would prefer to pay monthly for real-time information, 56% would prefer to pay on a per-call basis, 22% would not use the service for a fee, and 5% were unsure.

A case study on SmarTraveler, an ATIS that provides real-time location-specific traffic and transit information in the greater Boston area via telephone reveals that, for non-users of SmarTraveler, the higher the expected benefit from an ATIS (i.e., reliability, relevance, coverage, etc), the higher their willingness to pay.  For users, the utility of SmarTraveler is strongly affected by the users' level of satisfaction with the service [15].  That is, as long as they continue to be satisfied with the service they are using and the information they are obtaining, they are willing to pay for it.

The Real-Time Information Group [35], discussing a national strategy for British transit agencies, emphasized the importance of partnerships—public-public and public-private.  Partnerships with other public agencies (transit or traffic) will allow transit agencies to share real-time data and thus respond to issues and service disruptions more promptly.  The Group recommends the adaptation of the “organizational approach first established for PTI2000[7] and which has demonstrated effective collaboration between authorities operators and suppliers.  The underlying principle is to separate out the project risk structure, so that those risks that are better managed by the private sector are transferred to the private sector, and those that are better managed by the public sector remain under public sector control.”

The Seattle MMDI Integration Case Study [27] indicated that it would take more than forming partnerships to get the private entities on board.  The document speculated that the lack of private entities contributing data is thought to be a result of their viewing data as competitive, business-sensitive information that they are not inclined to share without compensation or appropriate data ownership agreements.

The Group [35] proposed establishing formal data sharing agreements for all service delivery and information partnerships.  Such agreements would address intellectual property rights issues for performance data, limitations on use, and transfer of information between parties.

Along the same line, Advanced Public Transportation Systems:  The State of the Art Update 2000 [1] discussed transit partnerships with other agencies and the need to create a multimodal-oriented traveler information system that will help raise the profile of transit information.

3.6       Use of National ITS Architecture and Standards for Design and Deployment

The National ITS Architecture is a framework that allows for the deployment of interoperable systems within and across transportation modes.  The National ITS Architecture defines the functions performed by different ITS components and ways in which they should be interconnected.  It serves as guidance to develop systems and interfaces to support identified user services. 

On January 8, 2001 USDOT published the Federal Highway Administration’s (FHWA) “Final Rule” and the Federal Transit Administration’s (FTA) “Policy” on ITS architecture and standards in the Federal Register.  The final rule and policy are identical in technical content.  Their differences reflect the processes by which FWHA and FTA administer projects.

In summary, the rule/policy require regions deploying ITS projects funded with Highway Trust Fund (which includes transit projects funded from the Mass Transit Account) money to prepare regional system architectures, consistent with the National ITS Architecture.  Any ITS project must be designed to be consistent with the regional architecture, must be developed using a “systems engineering” approach, and must utilize any applicable ITS standards that have been adopted by USDOT (many have been developed by Standards Development Organizations but none have been formally adopted by USDOT).

Recognizing the importance of the National ITS Architecture, the FTA participated in its development process through an effort to identify transit-specific requirements.  FTA along with the U.S. Department of Transportation ITS Joint Program Office offers training courses, as well as published reports to educate the transit sector on the importance of the National ITS Architecture.  Courses are offered through the National Training Institute (www.ntionline.com) and the Transit Standards Consortium (www.tsconsortium.org).

The only two documents in the literature reviewed that touched on architectural issues and national standards dealt with European systems.  The Real-Time Information Group:  A National Strategy [35] proposes national “standards” to which all operators comply.  This will guarantee that “a national specifications will deliver a base level of functionality that will ensure that any purchaser will get a system that meets the functional aspirations of all classes of users.”

Similarly, by the mid-nineties, Centro [30] had already experimented with various real-time applications using beacon-based systems (i.e., signpost-based systems) and GPS.  Concerned about the proprietary hardware and software that seemed to be delivered with all systems, Centro specified a complete open architecture that would allow:

• Open architecture on the vehicle
• Open protocols regarding interconnectivity to a radio architecture
• Expansion capability for other modules, such as smartcards and automatic passenger counting.

Additional information on the National ITS Architecture, compliance with the FHWA/FTA rule and policy, and any standards issues may be collected during the specific site visits and telephone interviews on specific real-time transit information systems implementations.  Information collected on this subject will be included and addressed in the final guidance report.

3.7       Customer and/or Media Reaction

In general, customer reaction to real-time transit information systems seems to be of the greatest interest to most researchers and authors.  More than one quarter of the reviewed documents touched on this subject in one way or another and at various levels of detail.  Overall, customers seem to be very satisfied with most systems and believe that they are of great advantage to them.  Customers indicated that, with the provision of real-time transit information systems, they believe that the transit service is more reliable and efficient, that their waiting time at stops is shorter, and that they feel safer at stops.

Ciuna, Migliore, and Sabatini [24] used quantitative methods to correlate a customer satisfaction index at bus stops with both qualitative and quantitative factors, such as the presence of real-time information.  It was shown that the expectations regarding the quality of information to be provided could be twice the perceived quality of information actually delivered when the system becomes operational.  The mean value of the information quality (on a scale between 1 and 10) was about 4.  Installing a reliable, real-time information system at bus stops could raise this mean score to eight (8).

Given these results, it is not surprising that customer reactions have consistently been favorable toward real-time information systems.  Also, it is not surprising that researchers have devoted significant effort to studying and evaluating users reactions.  Appendix F provides selected summaries of user responses and reactions to various transit traveler information systems deployed in the US and Europe.

3.8       Agency/Staff Reaction

No information on agency staff reactions to real-time transit information was provided in the literature.  Although this area may not be as significant as technical issues, staff reaction to real-time information systems is still important.  If the staff are not aware of the available real-time information systems and their benefits, then it is unlikely that they will even consider deploying them.  It is for this reason that understanding staff reactions to real-time transit information systems (whether before or after deployment) is important.

4.0     NEXT STEPS

The next step in the project is to visit selected agencies (five transit agencies located throughout the country) that have successfully implemented real-time transit information systems.  The project team will prepare a site visit questionnaire that will guide them and collect relevant information on each of the systems deployed.  Subsequently, the project team will use the questionnaire to interview selected transit agencies (10 transit agencies) by telephone.  Table 4-1 lists the proposed transit agencies selected for site visits and telephone interviews.

Table 4-1:  Proposed List of Transit Agencies for Site Visits and Telephone Interviews

Site visit reports and telephone interview reports will be documented, and this information will be used to assist in preparing the guidance document.  The site visits and the telephone interviews are scheduled to be completed by mid October, 2002. 

Ultimately the objective of the project is to develop a “guidance document” which includes relevant information collected from this white paper report and the site visits and telephone interviews and provides “hands on” useful guidance to transit operators that may be considering the acquisition or development of real-time transit ITS systems.  The draft and final guidance report is scheduled to be completed in the first quarter of 2003.

Literature Review Template

Title :                             

Author:    

Source:  

1)

Type of Real-Time Information Provided

Transit Vehicle Location Display Pre-Trip Planning Estimated Arrival or Departure Time of Transit Vehicles Waiting time (countdown) until Next Vehicle Arrives En route On-Board Audio/Video Announcement Transit Vehicle Departure Location and Status Service disruptions Other real-time information (e.g., date, time, weather) En route Peripheral Info (i.e. advertisements, general system information) Other:

2)	Types of Media for Dissemination of Real-Time Transit Information
	Internet  DMS     Interactive Voice Response via Telephone Interactive Kiosks      Video Monitors PDA’s Fax Non-interactive Kiosks  Telephone (voice information) Wireless application protocol (WAP)-enabled mobile telephone Cable television Other:

3)         Issues and problems associated with planning, implementing and operating real-time transit information systems.  Potential Solutions to each problem/issue (if available).

4)         Techniques for data collection, fusion and dissemination

5)         Transit ATIS Infrastructure and business model

6)       Use of National ITS Architecture and Standards for deployment of real-time transit information systems

7)       Customer and/or media reaction to real-time transit information

8)       Agency staff reaction to real-time transit information

9)       Institutional/organizational issues associated with real-time transit information system.  Potential solutions to each problem/issue (if available).

APPENDIX B

LIST OF SOURCES SEARCHED AND/OR REVIEWED

APPENDIX D

LIST OF TRANSIT AGENCIES INCLUDED IN LITERATURE

APPENDIX E

LIST OF REAL-TIME SYSTEMS INCLUDED IN LITERATURE

APPENDIX F

USER RESPONSES AND REACTIONS

TO SYSTEMS IN US AND EUROPE

---