As a design/liaison engineer contracted to an Advanced Light Transit RailCar project, I was tidying up production drawings for series production. After a while, I was transferred to Quality Assurance, which had reams of test data from the test site piling up. This information was used to keep on top of revenue service by analyzing the test results and, where applicable, carrying lessons learned back to revenue service. Statistical evidence was nonexistent except anecdotally, and the company was spinning its wheels, so management wanted the IBM room to provide them with comprehensive and legitimized reports.
An IBM representative and I figured out a way to get relevant data into the computer. When it was set up, I started logging in the test results in a random fashion.
After a couple of weeks of data entry, my boss dropped in to see how things were working out. He asked for a demonstration. He was curious about a large proliferation of error code EC33 and asked if our data could reveal anything about that. So we set the computer to run a search for EC33 and printed out a report, which told us that a large cluster of EC33 was located at a certain quadrant of the test track. When I asked the boss about the significance of this, he told me to talk to the track people.
I marked up a copy of the test track map and trotted along to the track people. They told me that that section had solid double back iron, which was used both to accelerate the linear motored railcars and to brake them using regenerative means.
Regeneration was the responsibility of the Power Group, so I asked them if they had made any changes to that sector of track. Yes, they said they made changes when the solid double back iron was removed. They reset the regenerative power spike in their system. I told them the solid double back iron was still there, and this caused all sorts of consternation, because they had been trying to trouble-shoot many of the EC33 codes that kept showing up.
What happened was that as the railcar entered the sector, the computer began regenerative braking prior to the car reaching a station, and the rate of deceleration was continually adjusted through the Power Group's controller. What confused the controller was the high value of regeneration and braking caused by the still-in-place solid double back iron, and it adjusted accordingly. When the railcar left that condition, it closed rapidly on the station, invoking an error code EC33 and shutting down the system.
Therefore, some of the EC33 had no relevance in the records. We went back to the Power Group and determined the date on which they had adjusted their system. That allowed us to set aside suspect EC33 for further evaluation.
The value of the simple program (and it had to be simple, since the IBM guy and I were feeling our way through the procedure) was sensational, since now data could be poured into the IBM machine, and relevant reports became part of management's decision paperwork.
This entry was submitted by John Mitchell and edited by Rob Spiegel.
John Mitchell was self-employed through Mitchell Research. He worked mostly in aerospace design/liaison engineering with excursions into product/quality engineering on batteries, forensic engineering analysis, and Hovercraft. He is now retired and working on vertical axis wind turbine systems and small electric vehicles.
Tell us your experience in solving a knotty engineering problem. Send stories to Rob Spiegel for Sherlock Ohms.
Related posts:
Tweet This
12 
