Dept. of Transportation
Metro Transit Division

King Street Center
201 S Jackson St
Seattle, WA 98104
Metro Online Home

Appendix D: Technical Staff Debriefing Summary

Participants: Reta Smith, Wayne Watanabe, Martha Woodworth, Tony Longo, Ruth Kinchen, Tamara Davis, Brad Kittredge, Bob Syslo-Seel, Dan Overgaard

As part of the Smart Bus Demonstration project evaluation, a discussion was conducted on April 15, 2002 with a group of King County Metro Transit technical staff to identify technical lessons learned and system wide implementation issues raised by the demonstration.

The group was provided with an update on the technical results of the demonstration:

  • Onboard and base equipment start up and operation;
  • APC assessment;
  • GIS assessment

The updates were followed by discussion of the potential implications for the OnBoard Systems project implementation.

Discussion Highlights

The following discussion highlights present key issues and observations identified by the discussion participants. Detailed results from the APC and GIS assessments noted below will be available in separate sections of the Smart Bus Demonstration Evaluation report.

Demonstration On Board equipment

Overall, the hardware and software installed on the bus worked reliably and did not break down.

The dynamic data on the bus was stored on a PCMCIA card, as opposed to the vehicle logic unit (VLU). The demonstration equipment configuration did not test the VLU as the primary storage and processing mechanism for dynamic data.

Implementation issues and considerations:

  • Installation of the 24 discrete input outputs (I/Os) on the demonstration coaches took the vendor a considerable amount of time. It is expected that with experience, the process can be streamlined and standardized, but is likely to remain labor-intensive.
  • The set up of the stops and route database onboard the bus involved collecting GPS location coordinates for each bus stop and every 50 feet along the bus route. How will this be accomplished in implementation? The project team is considering options for the system wide process, including collecting the information while buses operate in service, or using the Transit GIS map.
  • The accuracy of transit stop sequence data remains an issue for the project. Discrepancies in stop data were identified throughout the course of the demonstration by various analysts. A goal of the Stop Information System project is to increase the consistency and accuracy of stop sequence data for the OnBoard Systems project.
  • The group identified transit operator training issues related to the stop annunciation function including:
    • What does the system consider as off route operation and how will the system behave?
    • By what process will transit operators report errors in stop announcements?

WDOLS and base equipment

Throughout the demonstration, data was communicated between the bus and base server via a wireless data offload system (WDOLS). The automated wireless communications system automatically transmitted vehicle performance data from the vehicle each time it returned to Central Base and provided automatic data and software updates to the vehicle.

Implementation issues and considerations:

  • WDOLS will require security measures to prevent hacking of the base servers, KC WAN, or the equipment on the buses.
  • Adequate emergency power supply will be an issue as more systems are installed at the base facilities: security cameras, onboard systems, Smartcard.
  • The number of systems sharing the base servers will increase the need for server management and coordination.
  • The base servers are not expected to be managed by base staff but rather by King Street Center staff.

APC Assessment

The group reviewed the results of the APC assessment. The demonstration APC equipment performed well overall, but did not fully meet current APC program specifications.

Implementation issues and considerations:

  • The need for clean source data was highlighted in this analysis, as errors were seen in the stop sequence data. The ability to identify errors in stop sequence data and correct them in a timely manner will be a critical implementation issue.
  • In an onboard systems environment, APC post processing will be eliminated, but the volume of data managed by staff will increase. The impact on APC staff and work processes will need to be assessed including:
    • the data quality and troubleshooting processes;
    • the required toolset for managing and troubleshooting APC data;
    • staffing requirements.

OBS Data management

Implementation issues and considerations:

A large body of work exists to address the following onboard systems data management issues:

  • By what process are data from the onboard database parsed to the various user databases, for example APC, fare collection, etc?
  • How much data will be stored on the bus before it is overwritten?
  • The resulting historical database is potentially very large. Database issues include:
    • Database structure to allow comparison of planned vs. actuals;
    • How much data is stored and for what duration?
    • What data are stored in summary form, such as averages, vs raw data?
    • What are the legal requirements for historical data, such as L&I, safety?
    • How will the data be viewed by users?
  • Implementation of the biweekly scheduling process in onboard systems environment. By what process will schedule versions be controlled and updated onboard?
    • The project team envisions an automated process for implementing current and next service change onboard, including a trigger for when the bus should use the next service change data set.

GIS Assessment

For this assessment, demonstration onboard stop event data was mapped onto the Transit GIS map. Overall, the demonstration stop event locations coincided fairly closely with the GIS stop locations, averaging 72 feet from the GIS stops, with a standard deviation of 64 feet, and a range of 3 to 510 feet.

Implementation issues and considerations:

  • The variability between onboard stop events and Transit GIS stops on 3rd Avenue in downtown Seattle, suggested the "urban canyon" effect of "raw," unenhanced GPS technology, where the global positioning satellite signal cannot be received by the vehicle if it is surrounded by tall buildings or hills. The vendor AVL product provided an algorithm to correct the vehicle's determined location if the GPS signal was inadequate. In the demonstration installation, this feature was not used to correct the location data in the onboard data record, but only for the stop announcement and display functions, which worked well in downtown Seattle with no apparent urban canyon effect.
    • Overcoming the potential urban canyon effect will be a significant challenge for the effort. Options suggested by the group included retaining some signposts from the current AVL system, or supplementing the CAD interface with a "snap to" function with additional logic.
  • Areas outside downtown Seattle showed several instances of demonstration stop event data clustered hundreds of feet away from the GIS stop, suggesting the GIS stop location may be in error. Stops are placed on the Transit GIS map relative to the street network, not map coordinates collected in the field, and are the more likely source of error.
  • One option to explore would be to define a bus stop spatially as a zone or distance, rather than as a point, to improve the appearance of OBS stop data on the Transit GIS map, and to provide a more realistic representation of a bus stop.

Demonstration Automated Vehicle Location (AVL)

Discussion participants noted that while not yet confirmed by the Smart Bus Demonstration vendor, it appears the onboard AVL function relies heavily on its odometer and gyroscope readings to determine location, corrected by GPS data when the coach opens its doors at a stop. It was noted during off route operation of the demonstration coach that the stop announcements feature resumed when the coach returned to its expected route and had serviced a zone. If this is the case, such a "synching" mechanism would not work well for routes with few stops or during night service.

Implementation issues and considerations:

  • A mechanism to trigger more frequent synchronization with GPS should be explored, such as changes in heading (direction of travel) from the gyroscope.
Updated: Sept. 2002