Daimler-Chrysler ESD Test Change in DC-10614

  

Changes

  

Daimler-Chrysler (DCX) has recently revised one of the tests in DC-10614. They have changed the way that the operating ESD test in done for component level testing. In the previous version, the test was done in accordance with IEC 61000-4-2, using a horizontal and vertical coupling plane to couple the discharge to the DUT. However, problems started showing up that appeared to be ESD related but could not be repeated when performing the test as per the specification.  After some research and more testing, it was found that the failures were being caused when a discharge occurred, say to the door handle, and it was being radiated to a nearby harness and causing a problem. So they have now devised a new method, using a conductive harness support similar to the capacitive coupling clamp used for transient testing of I/O lines but without the top cover. 

  

New Test

  

There is a non-conductive support, 1.7 meters long and 50 mm high, connected to and placed on the ground plane. This has a copper strip mounted on top with discharge "islands" spaced 500 mm apart. The DUT harness is placed on this and the ESD gun is discharged to the "island" and thereby coupled to the harness. Depending on the DUT classification, this test is conducted up to 25 kV. It seems that this method is more of a "real world" way of doing the test than the previous version and appears to be much more repeatable.  

  

More Problems

 

I think more problems like this are going to crop up in the future, what with modules being interconnected and running off of some sort communication bus. A problem could occur on the bus that knocks out the instrument cluster. It goes back to the dealer for repair under warranty, they replace the cluster and everything works again. When the supplier gets back the returned cluster, they test it and find nothing wrong. Meanwhile the real problem was with some other module that screwed up the bus, but that problem went away when the cluster was replaced and the system reset. You can test a module until the cows come home, to prove out the hardware and software to ensure that it meets all the customer requirements. Unfortunately, how do you predict how that module is going to behave when it is installed and connected to a communication bus and interacting with several other modules? 

  

Historical Example

  

Some years ago, my company made an electronic PRNDL module (gear indicator). It used a single wire UART communication bus. This was even before J1850 or CAN. After it was in production for several months we started to get customer complaints that while the vehicle was in Drive, every so often the Park LED would flash on and off. They sent units back, but no matter what we did with them, we could not duplicate the fault. We finally had to ask for a vehicle with this problem. After getting one and driving around for awhile, we were able to duplicate it. However, it only showed up if you drove at a certain speed, there was a quarter tank of gas and the traction control was on. If all those conditions were met, sure enough the Park LED would flash when in Drive. Turns out there was an extra bit in the data stream that our module was seeing and that's what caused the LED to flash. We had to make a change in the software code to fix it. This was in the days of hard masked micros so the change took a while to implement. At least nowadays, everything seems to be going to micros with flash memory, so making software changes is relatively easier than it was in the past.

   

  

Anon. 

September 2004


www.AutoEMC.net 2004                                                           TOP OF PAGE                                                                 HOME