Dept. of Transportation
Metro Transit Division

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

Appendix B: Vehicle Maintenance Staff Debriefing Summary

Purpose:

As part of the Regional Smart Bus Demonstration Evaluation conducted by King County Metro Transit, a discussion was held on February 14, 2002 with King County Metro Transit Vehicle Maintenance staff involved in the demonstration. The purpose of the discussion was to summarize Vehicle Maintenance staff experience with the demonstration automated vehicle monitoring (AVM) functions, lessons learned, and suggestions for improvements for system wide implementation. Management Information & Transit Technology staff facilitated the session.

The Smart bus demonstration AVM functions installed at Central Base included:

Mobile TA Tools: Installed on a PC in the hostler's shack (vehicle maintenance dispatcher's office), this tool allowed VM staff to obtain a snapshot of several coach conditions as the demo coach returned to the base. Normal conditions were displayed on the screen as green, a temporarily out of tolerance condition was displayed as yellow, and a currently out of tolerance condition was displayed as red.

TA Tools: This tool provided VM staff with next day access to detailed AVM coach data via pre-defined web reports.

Custom data queries: Upon request, the Smart Bus demonstration vendor provided detailed printed data reports based on the Smart Bus demonstration data files.

Discreet Input/Output monitors: Sensors were installed at 24 selected points on the demonstration coaches to monitor for changes in equipment status, e.g. "doors open" or "doors closed." The data from the I/O sensors was not available on either version of TA Tools.

Discussion Summary

AVM Data:

Great potential, but user requirements needed

In general, Vehicle Maintenance staff said they found great potential in the automated vehicle monitoring demonstration functions, but found little utility in the functions as implemented in the demonstration. To be useful to Vehicle Maintenance staff, the type of information collected by the system would need to carefully match staff needs, and improved reporting and data analysis tools would need to be provided.

Initial accuracy issues

According to participants, both Mobile TA Tools and TA Tools displayed some inaccurate data in the first few weeks of the demonstration. These were identified as software data translation errors and were subsequently fixed by the vendor. In the meantime, users lost confidence in the system and stopped using Mobile TA tools, but continued to work with the vendor on improving the TA Tools web reports.

Overall accuracy

Once the initial translation errors were fixed, participants considered the AVM data to have good overall accuracy. Apparent false readings turned out to be accurate when investigated further, but some looked unusual at first because the data required some interpretation, participants said.

Use of AVM data to identify problems

When asked if the system was ever used to identify a vehicle problem, participants noted the system indicated a yellow status "out of range" reading on coach 9024 for oil pressure. This was identified upon inspection by mechanics as a pressure switch problem, as well as low coolant. These problems, if unattended, had potential for eventually generating a road call, participants said.

Discrete I/O data most valuable

Demonstration data from discrete input/outputs (I/Os) provided the most valuable type of information as opposed to information from the vehicle's J1708 network, which currently can be monitored by gauges or a laptop, participants said. Examples of I/O data include: the 30 and 35 mph switches, fan control, rear door, and wheelchair lift cycles. Participants identified exhaust back pressure and air intake restriction as other useful I/O data items for a future AVM system. These would require the addition of sensors.

Sensors required for I/O data

Participants said some AVM I/O data items described by the vendor were not actually available, such as coolant level. The capabilities of the system are limited by the hardware installed on a coach. If there are no sensors installed on coach to collect the information, the system can't report it, participants said.

Coordinate with coach procurement for I/O sensors

In order to monitor discrete I/Os, participants said, sensors will need to be installed. By coordinating with Vehicle Procurement, new coaches could be specified with the sensors installed for each I/O of interest. Participants anticipated needing about twenty four I/Os.

Sensors could be moved if needed for equipment testing or monitoring a specific I/O on a specific coach type.

Lessons learned: data definitions need VM input

One of the lessons learned by participants from the demonstration was that more work is required in defining what items are monitored and how. Participants mentioned wheelchair lift use as an example. "The vendor is monitoring that power went to the lift, but we want to know whether the lift was deployed. We have different expectations of what 'monitoring' a wheelchair lift means."

Mobile TA Tools:

Discussion participants said the Mobile TA Tools function was not useful as provided for the demonstration because the information was generally available through dashboard gauges, such as the oil pressure gauge, and other readily available indicators.

Participants described the Mobile TA Tools function that displays coach status as red, yellow or green as "idiot lights" without an associated measure, such as degrees of pressure. In order to obtain detailed diagnostic information on the coach, VM staff still needed to plug a laptop into the coach (current VM practice), participants said.

Mobile TA Tools improvements

While data accuracy issues led to an early abandonment of Mobile TA Tools by VM staff, participants believed the concept is still a good one. The primary value of implementing such a function would be the ability to triage buses returning to the base according to their need for maintenance. According to participants, the function would need to provide:

  • An indication of conditions red, yellow or green, with red and yellow indicating out of tolerance conditions (as the demo system did).
  • Out of tolerance conditions would need to be accompanied by data indicating which component is having a problem.
  • The data would need to include information from discrete I/Os.

Better triage would save time and money

Identifying coaches with out of tolerance conditions as they pull into the base, before the coach is parked, would allow more coaches with problems to be parked in the "BO lane" or holding area for coaches with problems, rather than parked with the other coaches, participants said.

Current process generally relies on the transit operator to tell the hostler if the coach is "BO" (needs work) and needs to be parked in the BO lane. Participants said sometimes transit operators fail to mention problems, or they are not apparent to the operator, as in the case of equipment monitored by discrete I/Os. Coaches that require work are parked with the other coaches. If later identified as a BO coach, either through an operator request form (OR) or other means, the coach must be moved, requiring that surrounding coaches are moved out of the way. Participants estimate this happens at least once per shift at each base, taking approximately 30 minutes of staff time per incident.

Location of Mobile TA Tools

Participants discussed possible future locations at the base for Mobile TA Tools or similar type of equipment for triaging coaches. If located in the hostler's shack, the equipment would need to be staffed around the clock, so someone would be there to see the information displayed by the system. Participants saw similar staffing needs if the equipment was installed in the lead mechanic's office. Locating the equipment at the fuel building has an advantage, participants said, as all coaches are fueled daily, or in the case of trolleys, have their fareboxes pulled.

Electronic "BO" notification

Participants reacted positively to the proposal of providing transit operators with the ability to flag a coach problem by selecting a pre-coded item from the menu on the operator's driver display unit (DDU). This would not replace the current Operator Request (OR) or BO form, as a detailed description of the problem would still be needed by Vehicle Maintenance staff. Participants said this would be another means to help ensure problem coaches are identified.

Participants noted the coach's data and BO status would need to be cleared out, perhaps by a reset button or some other mechanism, to give the coach a "clean slate" following repair, to allow the coach to go out again. Otherwise, participants were concerned that a repaired coach might still appear in the system as BO or out of tolerance if the coach was repaired quickly and sent back on the road.

TA Tools (Historical web reports):

The TA Tools web reports provided detailed AVM data to staff through canned reports distributed on the vendor's Internet site.

Data turnaround time

AVM data were available in the web reports the day after the coach pulled in to the base, not soon enough to really be useful, participants said. Ideally, detailed diagnostic data would be available in real-time, or at most, an hour after the coach's pull in at the base. This implies a server at each base, participants said.

Web reports not user friendly

The TA Tools next day web reports provided in the demo generally did not meet their needs, participants said. Participants noted the user interface was clumsy and required the viewer to go through many screens to finally view the data they wanted. The charts and scales were difficult to read, participants said.

Custom Data Queries:

Emphasis on exception reporting

When participants requested some special data queries from the vendor, they were surprised by the volume of data they received, for example, some measures were recorded every second. Upon viewing the reports, participants said, they really wanted to see the exceptions or out of tolerance items, for example all coaches with coolant temperatures above 250 degrees. In addition, some information makes more sense when viewed along with other data, participants noted, such as the 30 and 35 mph switch data should also include coach road speed.

Next System Reports:

Discussion participants said that in the next system, they would want to generate reports themselves by selecting desired data elements from a menu. The system must include reporting capabilities for discrete I/Os.

Participants said they will want some preset or canned reports, as well as the ability to develop customized reports themselves if necessary.

AVM Data Access

Participants expected the AVM data would be valuable to vehicle maintenance chiefs in identifying performance trends by fleet type over time. They expected chiefs, leads, and mechanics would need to query AVM data on a daily basis.

Potential benefits of diagnostic data:

Participants said quick availability of diagnostic information will help reduce the time mechanics spend diagnosing problems. Vehicle Maintenance staff will be better able to identify which coaches can go back into service and when, allowing staff to more effectively manage fleet availability. In addition, participants said, VM staff would be able to manage their work flow more effectively by being able to identify the expected duration of a repair job and staff availability to perform the work. Participants expected more efficient repairs would allow them time to do more preventive maintenance.

Wheelchair lift use and PM

From the demonstration data, participants learned how little the wheelchair lift was used on coach 9024. Vehicle maintenance currently maintains wheelchair lifts through a preventive maintenance schedule based on vehicle mileage. Participants said they are interested in looking at lift usage vs. mileage as a possible basis for scheduling PM. The potential cost savings could be large if wheelchair lift preventive maintenance could be done more efficiently, as each PM requires approximately eight hours of labor.

Training important to success:

As some Vehicle Maintenance staff are not PC literate, participants noted, user training will be an important aspect of the project system wide implementation as well as "easing folks into it."

Updated: Sept. 2002