Tips for developing automotive test programs
Kim Lankford, CAN and data-acquisition product manager, National Instruments, Austin, TX -- Test & Measurement World, 11/1/2003
The cyclic nature of automotive manufacturing and the industry's extreme throughput pressures demand that you develop comprehensive test programs quickly. Although there is no magic spell that conjures up test programs for automotive electronics, we at National Instruments have come up with some tips that can make the process more successful.
1. Develop test modules instead of large test programs. Companies demand faster development cycles with ever-smaller engineering teams, so development efficiency is more important than ever. Developing independent test modules rather than large, fully functional test programs ensures greater flexibility. For example, with modular tests, you can easily re-use design-validation tests during full-scale manufacturing.
![]() |
|
Fig. 1. A typical block diagram showing measurement synchronizatoin. Photos courtesy of National Instruments. |
In addition, many automotive systems do not differ much from year to year. A modular test program allows you to concentrate on creating tests for those portions that have changed, again reusing tests written for those portions that have remained stable.
2. Synchronize measurements to correlate data for CAN device validation. When testing some systems, such as an electronic power-assist steering system, you must synchronize analog measurements (vehicle speed and torque) with the controller area network (CAN) control signals (assist-motor voltage). Because a test requires multiple measurement boards—one for analog/digital measurement and one for the CAN—the boards must share a start trigger to prevent start latencies. Without a shared start trigger, the software will start individual acquisition operations in a predetermined sequence. This sequence imposes a time difference between measurements that is unpredictable because of inconsistent operating-system activity.
For example, if the operating system executes a virus scan after the first acquisition starts but before the second one begins, the latency may be quite large. Similarly, even slight variations in the timing chips on the boards produce clock drift. Over time, minor differences become magnified, producing large errors between the measurements. Synchronization eliminates these errors, and sharing a clock between multiple boards eliminates that drift. Figure 1 shows a block diagram of the synchronization approach.
3. Integrate control functions into the test process. Most automotive control systems undergo static testing in the laboratory, but dynamic verification has to wait for testing in the field. When developing test programs, you can combine static and dynamic testing into a single step by incorporating real-time control routines.
![]() |
|
Fig. 2. Integrating control functions of the UUT facilitates verifying the unit's operating dynamics. |
4. Parallel testing increases test-system performance while lowering manufacturing and test costs. Providing each test site with a dedicated set of instruments is not a feasible alternative. Testing only one product or subsystem at a time leaves utilization levels for expensive test hardware at no better than 50%. Parallel testing, on the other hand, increases manufacturing throughput and reduces test equipment costs.
Implementing parallel test-system architecture often does not require any additional hardware investment. You can share existing test-system instrumentation among several test sites, reducing idle time during a UUT test cycle. In many cases, adding inexpensive instruments while sharing the most expensive equipment across all of the parallel sockets can further optimize system performance while minimizing cost. Keep in mind, however, that some circumstances still require a separate hardware setup for each UUT.
5. Use a multithread operating system to improve test-software efficiency. The upper end of automotive-test applications has begun to push the boundaries of processing capability. While you might want to purchase a new PC with the latest processor operating at the fastest possible speeds, exploiting the multithreading capabilities of the existing operating system can improve test-program performance at lower cost with much less difficulty. While some test-program-development tools cannot expose multithreading functions to the user, others provide a simple method for taking advantage of them.
Fig. 3. A
test-data management system can simplify
tracking.
6. Create an automotive test-data management system. Three steps for creating such a system apply to any automotive test—including engine test and safety validation:

- Identify the descriptive attributes you would like to use to locate your data—for example, UUT serial number or part number or test date. These attributes will allow you to locate your data more easily, whether you want the test data for a specific unit or the test data for all UUTs tested during a certain time period.
- Modify your data-collection programs to save data to a database table. You likely are already recording many of these descriptive attributes in the headers of your data file, so you should extend your collection programs to insert that data into the database table.
- Use the data-searching and data-mining features of your existing reporting tool. Once you have stored the attributes in a database, you can use them to locate specific information. You need only provide an interface to select and retrieve the data for reporting. Figure 3 shows one output screen for a typical management system.
7. Share data with colleagues to improve test and troubleshooting efficiency. Often, colleagues in other departments and other facilities need access to your test results. Printing the results to share with colleagues creates a paper trail, but this "brute force" approach carries its own drawbacks. By taking advantage of the Ethernet bus and the Internet, you can share results with other people no matter where they are located or what platform they are using. Some software programs include Web-publishing tools that help you format Web pages that display your automotive test data.
8. Use software to set up your switching hardware. You can reduce the cost of building an automotive test system by using a switching system to connect a large number of channels to a small number of test instruments. To route the signals, you can take advantage of programs that simplify switch-system configuration. For example, one common automotive test measures the fly-back voltage on an ignition coil. Instead of spending extra time with assisted routing, you can use off-the-shelf software to define and name switch routes that you can later call from your test application.
9. Configure sensors using a transducer electronic datasheet (TEDS) and virtual channels. Automotive tests often involve acquiring data from many different types of sensors—thermocouples, strain gauges, accelerometers, and positive sensors. For each sensor, you need to configure scaling, excitation, and calibration. Manually entering and tracking these values is time-consuming and can result in errors.
The proposed IEEE 1451.4 standard (Ref. 1) defines TEDS for automatically configuring sensors. TEDS helps you load the sensor data either directly from an EEPROM on the sensor or from a Web database of virtual TEDS. With the manufacturer's name and serial number or part number of your sensor, you can download the virtual TEDS file.
Once you have the scaling data on your test computer, you also need driver software that can help you map that information to input limits and other settings of your data-acquisition device. These virtual channels can then be used in application software to analyze and acquire data properly scaled to physical engineering units. TEDS helps decrease configuration errors, simplify test-system setup, and shorten development time.
| Author Information |
| Kim Lankford is a product manager for industrial communications products at National Instruments. Her responsibilities include managing CAN, serial and automotive networks. She joined NI in February 2001 and holds a BS in chemical engineering from Arizona State University. |
| Reference |
|



















