Automotive Electronics Presents Challenges For Functional Test
Modern vehicle electronic systems have become technologically diverse. They bring power electronics, communications technology, and safety-critical systems together into a harsh environment of heat, cold, vibration, and high levels of electromagnetic interference.
Companies building these systems face yet another demanding task—testing them. Functional tests now must simulate the vehicle environment in ever greater detail while maintaining throughput and keeping costs under control.
The modern engine-management unit, a front-line, fundamental assembly, provides some of the most demanding challenges in automotive testing:
Simulating high-voltage and high-current waveforms and routing them to the unit under test (UUT).
Capturing multiple events and time domains the first time, every time.
Keeping throughput high by avoiding the multiplexer.
The engine-management unit is at the hub of dozens of sensors. It also is a sophisticated communications device managing instruments and indicators that handle everything from security to transmission settings. Typically, it may have more than 100 I/O pins with a wide range of functionality, some of which are illustrated in Figure 1.
Test engineers normally are presented with a black box and some heavy-duty automotive connectors. By the time the tests are complete, the manufacturer must be confident that the product will work once fitted in the vehicle.
The verification of the product normally falls into distinct classes of activity: establishment of communications with the product, static verification of pin functionality, and run-mode simulation.
It’s Good to Talk
Communications with the product ought to be simple enough. The standard communications protocols, CAN, VAN, and J1850, are widely documented. However, the communications issue is not that straightforward.
Manufacturers have their own little deviations to the standard implementations, and the actual codes to make the UUT work are proprietary and highly confidential. It means that there are many hours of digging for information while developing the communications test programs. Because most of the UUT diagnostics are carried out via communications, it is hard to tell if the problems are with the test program or the UUT. As a result, it generally is a major milestone when all the test-program communications are working.
Even then, there is a pitfall. Communications frequently are access-limited, and some commands, if sent, will lock the UUT completely. This can be frustrating when building an application, especially if you have only a handful of samples with which to work. The only advice is to keep a good relationship with the design team—and be careful.
Static Exercises
Once communications are achieved and stable, the second phase of the test is the static verification. This amounts to forcing the unit into the diagnostic mode to exercise the systems on board, in isolation. To the experienced functional test programmer, this should present few problems. However, the design specification is critical and should indicate what is expected of the UUT, what stimulus to apply, and what to measure.
Generally, the trickiest tests involve high currents or voltages, anything from 250 A to 1,000 V. Frequently, the high-power FET devices used to drive the coils and injectors must be checked for leakage. This means stressing the drain/source with approximately 500 V while the UUT is idle. A reliable, low-current measurement is required. Later the same drive components may be switched on and pass up to 30 A of current.
There are a few routing matrix cards that can manage this, some integrating the current measurement as well. But great care must be taken when programming them since most of them cannot change state while on-load.
Loads themselves deserve a mention. Automotive applications need a large number of them. Some simulate switches while others pretend to be everything from a bulb to an injector. Complex loads are very common. It is helpful if these are not mounted in the fixture but built into the test system.
Another common requirement is to drive the output from an arbitrary waveform generator (Arb) through an operational supply to provide floating high-voltage or high-current signals. There are few Arbs that produce floating outputs so an isolation stage generally is required.
The operational supply also can provide programmable protection and dynamic limits that need programming in a similar way. Operational supplies can be bought with GPIB interfaces, but they are too slow for dynamic signals such as those expected from a crankshaft sensor, for example.
Taking It for a Drive
Now that the product appears to work in the static mode, will it start a real car? To find out, we come to the run mode. This is intended to simulate a typical journey for the target vehicle, a necessity considering the complexity and intelligence of the UUT. Without this, there always will be the doubt that it actually will work in-situ. It is not intended to be an exhaustive check.
The run mode could be recreated by modeling the systems of the car within the test programs, so a more pragmatic approach is common. Generally, data is collected by sending a test car, packed with data acquisition equipment, from a standing start to 40 or 50 mph and then braking to a halt and shutting down. This information is passed to the test engineer in dozens of spreadsheet files for deciphering.
Fortunately, some of the data can be ignored because it is in a continuous on or off state. What remains of the data has two classes: non-time-critical waveforms and synchronous waveforms.
Non-time-critical waveforms can be stimulated using the program to manage the stimulus; these are logic levels, analog voltages, or simple waveforms. Synchronous waveforms must be carefully set up with Arbs and run simultaneously in hardware or the UUT will detect an error and shut down. The best examples of this are the crankshaft and camshaft signals. Bringing all this together in real-time is something of a challenge.
In many ways, the worst headache is collecting the data and making some sense of it. The time domains in which things happen are quite varied. Some events require seconds or even minutes for complete capture, while others need only tens of microseconds. The number of channels of analog data to be captured simultaneously can be 20 or more.
To accomplish this, a big, powerful data recorder is required. Some ATE and in-house-designed test equipment struggle with the wide range of sampling modes and large number of channels, not to mention triggering and memory depth.
Wayne Kerr has developed a card that monitors eight channels of data independently, each with its own time base but with common triggering. Since more than one card can be used, this provides the coverage required.
Even with this approach, there still is a problem with the volume of data and depth of memory. For the majority of the time, the focus is on whether pulses have occurred when expected. If a test system monitors just the events and not the details, it can store minutes worth of data in a few tens of kilobytes. A module is available that captures events on up to 24 channels. All you have to do is set up a threshold level and wait for the time-stamped results.
The Need for Speed
All of this amounts to a UUT that has been given a full functional test and verified under true-to-life conditions. The trend is toward ever more thorough run-mode tests and more I/O. At the same time, speed is of the essence, forcing test engineers toward more parallel testing, faster analysis, and optimized test code.
Looking for events rather than waveforms can make significant improvements. Another approach connects the fixture pins directly to the test resources without multiplexing, which can cut test times dramatically and increase accuracy by removing steps from the program and switches from the path.
About the Author
Paul Attwell is a product specialist at Wayne Kerr Electronics. He also has worked as a design engineer and as a project manager. Mr. Attwell, a chartered engineer, graduated with a B.Sc. in electronic and electrical engineering from Newcastle upon Tyne Polytechnic in 1983. Wayne Kerr Electronics, 11 Sixth Rd., Woburn, MA 01801-1744, (781) 938-8390, www.waynekerr.com.
Copyright 1999 Nelson Publishing Inc.
September 1999