Never Assume

I’ve been out of the business for several years now but I think this story might still be of some interest. This is a story of why, when listening to a reported problem, you should listen closely. It’s too easy to assume that it’s just another complainer blaming the system for their error or inconvenience. Often that is the case, but assuming so will get you in trouble.

Many years ago, we received a report from a train engineer stating that as he approached a crossing, vehicles were stuck on the track and they barely cleared the track before he arrived. The engineer was a good witness, not the norm I must say. He also said he was the second train through the intersection. A train had just cleared the intersection in the opposite direction just before his arrival. As it turns out, this was vital information.

It points out why a little conversation with the person reporting the problem can often provide the information needed to really help identify elusive problems. If you make it a habit to get a little extra information and pass it all on to the responder, you or they will have more information to use when those elusive problems appear. It also may help eliminate some of those no problem found responses.

I was the maintenance supervisor but, I went out to the intersection immediately and checked the report myself. Everything was working properly. Another no problem found report, right. Wrong!

Remember, the engineer said he was second train arriving just after the first train cleared. When tested in that way, the system still worked perfectly, but not correctly. As it turns out drivers are pretty stupid, in general. Sorry if that offends some, but it is a fact. Here’s why it was a problem.

After the first train cleared the crossing, the railroad arms started up. Our traffic signal was still in preemption completing its return to normal operation. The lights for the track crossing were still red but those stupid drivers started across as the arms lifted, against a red light on our traffic signals. As the second train approached, the arms started down again, but the traffic signals don’t respond to the second preemption because they haven’t completed the first yet. They were still protecting the crossing by giving a red light to the cars that were now moving onto the track. Basically this is just during the yellow interval of the preemption hold phase, the phase that is eventually green and stays green as the train passes. If your controller does a mini cycle during that hold, it would be the yellow of the last phase to be served before it returns to normal operation. It’s only about 4 seconds but it’s important. So, a bunch of cars are left sitting on the track and don’t get a green light to get off. Evidently they weren’t all too stupid and must have decided to turn right or something.

The manufacturer of the controller was notified and reprogrammed the controller to respond to preemption during that last clearance interval of the return from preemption. That fixed the problem. It only took about two weeks to get the fix in, quite responsive on the manufacturer’s part. Not the norm.

Shortly after I arrived at the intersection, I met the railroad’s signal maintenance supervisor there. He also was quite concerned, as I was. Just a few weeks earlier, a bus had been hit at a crossing in Pennsylvania. That had heightened concerns I’m sure. That’s why I responded immediately as well. Anyway, after we had identified the problem, he made an adjustment to the timing of the arms so they would stay down another 4 seconds. That had to be temporary because of a railroad rule that the arms clear within so many seconds after the train leaves the crossing. That made the problem safe while we waited on the manufacturer of our controller to make the change that was needed. Mind you, the controller worked perfectly, just not correctly.

The railroad supervisor reported back later that day that he had checked the other 22 crossings on the line and all but one responded the same way. My guess is that the one working intersection was quite old and didn’t have a microprocessor based controller. I have always wondered what action was ultimately taken at all the rest of the crossings.

The moral is: Stop, Listen, and Look, so to speak. Stop and listen to all problem reports. Look into the problem as if there were a problem, rather than assuming a first successful test proves everything is OK.

Next Meeting and Bar-B-Q May 16th, 2007

Date: May 16th, 2007
Location: City of Cupertino Corporate Yard
Address: 10555 Mary Ave. Cupertino, Ca. 95014
Time: 10:00 A.M.
Speakers: Mike Malcuit with Advance Traffic Products Presents the Wavetronix SmartSensor Advance SS200 System featuring Digital Radar.

Bar B-Que Lunch will be provided following presentation.

Minutes for the March 2007

TSA had a great turn out at the County of Santa Clara Corp yard March meeting where members got a chance to meet and greet each other while enjoying refreshments before the meeting and then the meeting was opened by Vise President David Mooso and the minutes for the last meeting and the Treasurers report were read by the Secretary Armando Herrera.

Amant Prasad with the County of Santa Clara gave an excellent presentation on the results of a study conducted by the County of Santa Clara on bicycle safety, detection and timing. For more information on this presentation you can see a video clip on the County Roads and Airport website at

The election results for TSA-SVC Officers were read and Roy Dexter with McCain was elected as new President, David Mooso with the City of Campbell was re-elected as Vise President, Ellen Martinez with Jam Services was also re-elected as Treasurer and Robert Asuncion with Republic ITS (Intelligent Transportation Services) was elected as the new Secretary.

Congratulations to all of the TSA Silicon Valley Chapter.