PC-Based Simulation and Monitoring of Automotive Electronic Control Modules

Author(s):
Chuck Karam - EG&G Structural Kinematics

Industry:
Automotive

Products:
LabVIEW

The Challenge:
Developing a PC-based system for automated testing of automotive electronic control modules (AECMs).Using SCXI and DAQ boards controlled by LabVIEW.

The Solution:
Using SCXI and DAQ boards controlled by LabVIEW.

Introduction
When EG&G Structural Kinematics needed an automated, repeatable means for testing automotive electronic control modules (AECMs), we developed a PC-based system using SCXI signal conditioning modules and DAQ boards controlled by LabVIEW.

What Are AECMs?
AECMs are electronic units that provide engine and power train control for automobiles. They receive signals such as transmission speed, crank and cam shaft speed, throttle position, absolute manifold pressure, and O 2 concentration. This information is processed by the module to generate signals to control engine and power train parameters - signals such as fuel injector timing, spark timing, tachometer, and engine warning lights.

System Requirements
To test AECMs, we needed to simulate and monitor various driving situations accurately. For the simulation, the AECM must "think" it is receiving the actual signals from the vehicle. For example, throttle position must correspond to the cam and crankshaft signals. Incorrect relationships between these signals cause the module to generate fault codes. The system generates six analog output waveforms, each at a rate of 10 kS/s. To complete the simulation, we program the test system to create driving scenarios called modes - such as Park Idle, 50 mph Uphill, and Wide Open Throttle. Several modes are then chained together to create a profile. We then play, repeat, or chain together profiles to perform the complete driving simulation for the module.
Concurrent with simulation, the test system monitors AECM output for correct responses. We monitor 48 analog voltage at 20 Hz per channel, 12 analog voltages at 2 kHz per channel, and an RS-232 line for output codes. Each of the analog channels requires independent, programmable alarm limits. When an alarm limit is reached, all data are streamed to disk beginning 2 seconds prior to the alarm and continuing for 4 seconds afterward. The aggregate rate for input is 25 kHz. Total system throughput (both input and output) required is 85 kHz. For the user interface, we need a con-tinual display of system status parameters, such as present position within a profile, alarm limit information and status, and manual event recording.

Hardware Design
The system consists of a 486 PC containing three DAQ boards - AT-MIO-16F-5 and AT-MIO-16 multifunction boards and an AT-AO-10 analog output board. The analog signals are connected to the MIO boards with eight SCXI-1140 simultaneous sample-and-hold signal conditioning modules. In the test scenario, the AECM outputs must be loaded with hardware components such as speedometer, tachometer, and warning lights.

Signal Generation
A significant portion of the AECM Simulator/Monitor is waveform generation. We generate crank, cam, wheel speed, and mass airflow sensor signals, carefully maintaining accurate amplitude and phase relations. These waveforms are either sine or square waves of variable frequencies to simulate engine speed. These frequencies are held until a new mode is invoked. The waveforms are output in real time using the AT-AO-10 analog output board. The NI-DAQ® driver software uses direct memory access (DMA) to avoid placing a continuous burden on the CPU, which also monitors, alarms, and updates the graphical user interface (GUI). Because some of the modes are very long (hours), we regenerate short periodic waveforms to avoid using huge waveforms that will exceed computer RAM. When the waveform frequencies ramp from one frequency to another, the software driver simply writes the frequency sweep waveforms into an intermediate output buffer and then seamlessly merges the waveforms into the output on the next regeneration. The sweep waveform must be immediately followed by a constant frequency waveform to prevent regenerating it. Phase and amplitude are maintained accurately because each point in each waveform is calculated and synchronously output. Additional non-DMA analog output channels generate varying DC voltages to simulate manifold air pressure and throttle position sensors.

Profile Development
Every drive profile in the system consists of several modes; each mode is created by the test technician using a mode editor we developed for specifying frequency values per channel and duration of play. These modes are given names and stored to disk. We also created a profile editor for targeting the mode files and arranging them in sequences with repeat options. We create the output waveforms by accessing the mode files.

Monitoring
While receiving drive signals, the AECM responds with outputs in the form of discrete analog and digital voltages, analog waveforms, and RS-232 codes. We can monitor more than 60 AECM outputs. The AT-MIO-16 board with SCXI-1140 simultaneous sample-and-hold multiplexers acquires data from 48 low-speed (20 Hz) channels. The AT-MIO-16F-5 board with SCXI-1140 multiplexers acquires 12 high-speed (2 kHz) channels. Once again, we use DMA technology to collect the data without requiring the CPU to perform the transfers. Every two seconds, the CPU completes its analog output check and reads the backlog of the analog input channels. It also checks the newly acquired data in the analog input buffers against the input alarm limits. If any channel falls outside the limits, the CPU then stores the data to disk. It also reads the RS-232 buffer to determine if any codes were emitted by the module.
The system updates the user interface after each iteration of the output and input service. The display indicates current position in the profile, alarm status, manual alarm override, and voltage levels.

Benefits of a PC-BasedSimulator/Monitor
The AECM simulator/monitor provides significant advantages over current methods of module testing. First, with the rapid development capability of LabVIEW, I was able to write the entire application over a six-month period while also leading the hardware development effort. Typically, test systems of this complexity have a team of people programming for that long.
Next, the test system provides repeatable, automated testing. Conventional module testing is performed with test sets built by the module manufacturer. Because such test sets are often controlled manually with potentiometers and switches, repeatability is very difficult to achieve.
Finally, using the PC-based system, we perform cost-effective yet thorough testing for the module development and verification phase. Cheaper and better are hard to beat!

For more information, contact:

EG&G Structural Kinematics

950 Maplelawn

Troy, MI 48084

Tel: (810) 637-6853

Fax: (810) 816-8763

Browse All Case Studies »