A wrong start-up sequence trips a 60 kW APU.
In the late 1990s I worked for a company that manufactured subsystems for rail transit cars: door operators, heating ventilating and air conditioning (HVAC) and other products. I was hired to be a “fireman”—not the real type, but to take care of technical problems that plagued any project.
About a month after my hiring, my boss came into my cubicle and told me he had a problem. One of our products—an HVAC system—was tripping the Auxiliary Power Unit (APU) and that I should investigate. He also tells me the design is from a company that we acquired and none of the people who designed it are working with us. I understand this means I am on my own.
Let me give you some background information on subway cars and tramways. Most cars are DC powered. Power comes in, at 600 V to 750 V depending on the system, and is sent to the traction system and to the APU. The APU converts the DC to three-phase AC, so it is an inverter. In our case the 60 kVA APU was powering only one thing, the HVAC unit.
My boss told me that I had to be at our HVAC factory, in upstate New York, by the next morning to witness the final test on a unit that was being delivered.
Next morning I’m on the factory floor looking at the HVAC unit. It is a top mounted unit; it will be installed on the tramway’s roof. It is about 3.5 meters long and 2.5 meters wide. A separate control box is installed in the car ceiling for easy access. The technician plugged the control box into a low voltage DC power supply, then connected the high voltage to the factory 208 V three-phase 60 Hz, turned on the DC supply, switched on the AC circuit breaker, and ran through the final test. I see no sparks, smoke, or other signs of overload or stress or loud humming. I talk with the technician and he tells me he has not seen any indication that the units manufactured to date cause overloads during the tests.
The next day I reported my findings to both my boss and the project manager. My next action is to go to the transit authority facility and investigate.
A couple of days later I am in a tramway car at the transit authority main repair shop. It is a new transit system: new cars, new tracks, and new shop. I meet with the transit authority technicians, the APU technician, and the car builder representative. They all confirm that the HVAC is repeatedly overloading the APU. The APU is designed specifically for the HVAC load for these cars. The transit authority requirements for the APU, the HVAC and all other systems are all written clearly in the request for bid documents. The APU technician informs me that the APU monitors its output current and after three overloads it will shut down permanently. Afterwards, the technician has to insert a USB thumb drive with special software to reset the APU. To demonstrate, the technician powers the car on and then off, and the third time he powers it up, the APU trips. We repeat the test a few times with the same result.
We came to the conclusion that to determine if the APU or the HVAC is the source of these overloads, we will have to take measurements in a car. This means having access to a lot of test equipment, a test car, personnel and other resources. I tell them I will go back and discuss this with my boss and the project manager to coordinate with all involved.
The next day my boss and the project manager both agree that measurements in a car are the way to go. The project manager informs me that the HVAC control box I requested is in my cubicle. I tell them that I will check it out. I hope to find a simpler solution than one that requires days of expensive on-site tests.
The HVAC control box is the size of a tower type PC. It has two connectors. The CPU reads the temperature then sends commands to the contactors and that’s it. The CPU writes the command words into two 8-bit latches; the latches control transistor buffers, the buffers control low power relays. Finally the relays send power to the contactors coils mounted in the HVAC unit itself. This way the high voltage is present only on the top mounted HVAC unit and not in the control box.
The turn-on reset circuit is complex. The CPU has its own reset circuit and the two output latches each have a separate RC network connected to the output enable pin. I connected oscilloscope probes to the latch output enable pin and to the write pin. The CPU writes data into the latch after the output enable is released! At power on, the latches are in an undefined state and the output could turn all the relays on. This means the fan motor, the compressor motor and all the heating elements are on. This amounts to twice the rated APU power. So this is likely the origin of the overload. It also explains why this was never seen during the final systems test at our factory. The test technician always applies DC for a few second before he can reach the AC switch.
I measured the time the CPU takes to write into both latches. I computed a new worst case value for the resistor in the output enable RC network. I changed the circuit from two separate RC networks to a single RC network with a longer time constant driving the two output enable pins. I also added a diode in the place left free by removing one of the resistors. This will give a faster discharge to the capacitor if power is lost momentarily. In case of a short duration power loss, the latch will lose its content but the capacitor may not have time to discharge sufficiently. The diode takes care of that case.
The modified unit worked fine and the delay between the write pulse and the output enable is conservative. I informed my boss and the project manager of my findings and described the simple modifications: remove three parts, add one resistor, a diode, and one wire. We decide that I will modify units to equip one train and send them to be tested by the transit company.
A couple of weeks later we got feedback that the modified units have cured the problem. I sign off on the ECO to have all the units retrofitted: case closed.
The take away is: always check the overall system reset timing with the final software before releasing the product; if possible test with the final system power supply, test different power on sequences and be ready to make modifications during system integration.
This article was originally published on EDN.
Daniel Dufresne is a retired engineer and has worked in telecommunications, mass transit, consumer products, and high power electronics and custom instrumentation design. He also was a professor at Cegep de Saint-Laurent and taught courses at Ecole Polytechnique de Montreal. Daniel published articles in Audio, EDN, Electronic Design and other publications. He lives in Montreal, Canada and still works on electronic projects and test equipment modifications and repairs.