Building Flexible, Cost-Effective ECU Test Systems

Overview

This white paper provides an overview of Engine Control Unit functionality and testing.

Table of Contents

  1. ECU History
  2. The Purpose of an ECU
  3. Why Test an ECU?
  4. Test System Developer Challenges
  5. How Does an ECU Work?
  6. ECU Functional Blocks
  7. National Instruments Virtual Instrumentation
  8. National Instruments Products for ECU Test Applications
  9. Conclusion

ECU History

Electronic engine controls, also known as engine control units (ECUs), have been around since the 1970s. At that time people were looking for a way to improve fuel economy due to the oil crisis and they wanted to find a way to make engines run cleaner and pollute less. At the time, engines used a mechanical device called a distributor to control spark timing and a carburetor to control the fuel mixture. This mechanical system had minimal tuning and adjustment capabilities. The advent of the microprocessor in the 1970s provided an enabling technology capable of performing the complex high-speed calculations required for controlling spark timing and fuel mixture. In the early 1980s, ECUs became a standard component in most vehicles. The ECU is a computer designed to solve a very specific problem. The ECU is usually the most complicated and powerful computer in an automobile.

Back to top

The Purpose of an ECU


Vehicles typically contain more than one electronic control module (ECM). An ECU is the ECM responsible for engine control functions. The primary purpose of an ECU is to provide closed-loop control of the fuel and ignition systems in an engine to improve fuel economy and reduce airborne pollutants produced by the engine.

Back to top

Why Test an ECU?


Test is often considered a nonvalue-added process. In a perfect world this makes sense, because in a perfect world the manufacturing process would never produce defects, system designs would always be flawless, software would always work as intended, there would never be any customer returns, outgoing and incoming quality problems would always be zero and testing would not be required because nothing would ever fail. However, because the world is not perfect, test is one method to guarantee minimal, measurable, repeatable, and traceable quality standards. Quality does have value even if the value cannot be measured directly.

Test is required for other reasons as well. Automakers have their own quality requirements and standards, such as QS-9000, as well as long-term traceability and regulatory requirements. Automakers usually require component vendors to test the products they manufacture before being shipped to the B&A (body and assembly) facility, where all the components are pieced together to build an automobile. B&A facilities are labor-intensive operations. Reworking an automobile because of a faulty component from a vendor is unacceptable and costly. Supplier contracts often include monetary penalties based on incoming defects directly attributable to the supplier.

ECU manufacturers are required to prove that their designs meet the customer’s specifications. This requires DV (design validation) testing. Manufacturers are required to prove that the manufacturing process can build devices correctly, which requires PV (production validation) testing. Quality standards usually require that a certain percentage of all ECUs go through a quality audit process to ensure the manufacturing process is not introducing certain types of defects. This QC Audit requires what is sometimes called continuing conformance (mini-DV) testing.

Back to top

Test System Developer Challenges


As stated earlier, test is often considered a nonvalue-added process even though test provides a means of improving the quality level of each phase of the manufacturing process. This situation places added pressure on test organizations to ensure that the test process is robust, thorough, fast, and cost-effective.

Test systems must be robust. Test systems must be able to operate 24 hours a day, seven days a week. Most automotive component vendors have high-volume manufacturing lines, where downtime is costly. JIT (just in time) manufacturing does not always allow partial, late, or missed shipments. False failures can contribute to downtime because of the mandates of the quality control procedures and processes required. For all these reasons, test equipment must be reliable and accurate.

Test systems must be thorough. They need to maximize test coverage and be accurate. Test systems should strive to prevent defects from appearing downstream in the manufacturing process. In general, the further downstream a problem is detected, the more costly the remedy.

Test systems must be fast. High-volume manufacturing requires that each stage of the process execute as fast as or faster than the slowest process. The test process must not become a bottleneck, especially because it is considered a nonvalue-added process. Test systems should strive to have some excess capacity relative to the slowest upstream process.

Test systems must be cost-effective. Test system designers must compare performance and cost. The true cost of a system is not limited to the purchase price. There are other obvious short-term costs such as equipment, training, maintenance, upgrade, support, and connectivity options. Long-term costs, which are less obvious, depend on parameters such as development time, flexibility, scalability, reusability, modularity, and portability. These factors are directly related to the hardware and software used in the test system.

As if this is not enough, test system designers have to make decisions within a limited budget in an increasingly limited amount of time. The window of opportunity for new products is becoming smaller and smaller. The life cycle of products is becoming shorter and shorter. New regulations, technologies and consumer demands are relentless and never ending. In the face of all this, test system designers must find a way to meet both current and future demands placed on the systems they build.

Back to top

How Does an ECU Work?


In simple terms, the ECU fulfills its purpose by accurately controlling the fuel mixture (air-to-fuel ratio), and spark timing (spark advance and duration) based on feedback from sensors connected to the engine. Management of the fuel mixture and ignition timing is complicated. The ECU requires data from many sensors to provide optimal control of the system. The ECU needs to know ground speed, engine speed, CRANK (crankshaft) position, air quality (oxygen content), engine temperature, engine load (for example, whether the air conditioner (A/C) is on), throttle position, rate of change of the throttle, transmission gear, emitted gases from the exhaust, and the list goes on. The ECU, as stated earlier, is a computer designed to solve a specific problem. Computers don't usually interact directly with the analog world. A signal-conditioning/data acquisition interface is required to convert the analog signals from the sensors to digital signals that the computer can understand. The digital outputs must be converted to analog signals to control the fuel system and the ignition system.

Back to top

ECU Functional Blocks


An ECU consists of a number of functional blocks:

1. Power Supply – digital and analog (power for analog sensors)
2. MPU – microprocessor and memory (usually Flash and RAM)
3. Communications Link – (e.g. CAN bus)
4. Discrete Inputs – On/Off Switch type inputs
5. Frequency Inputs – encoder type signals (e.g. crank or vehicle speed)
6. Analog Inputs – feedback signals from sensors
7. Switch Outputs – On/Off Switch type outputs
8. PWM Outputs – variable frequency and duty cycle (e.g. injector or ignition)
9. Frequency Outputs – constant duty cycle (e.g. stepper motor – idle speed control)

Figure 1 shows a block diagram of the typical I/O for an ECU. Each block lists the class of instrument that NI can provide for stimulus, measurement, and connection to loads and instruments.



Figure 1. ECU I/O Instrumentation

Power Supply

The ECU power supply is a DC-DC converter. The battery voltage is converted to voltage levels appropriate for the MPU and other digital circuitry. In some cases the ECU provides the source voltage for the analog sensors. In these cases, the ECU provides one or more analog supply voltages that are derived from the battery voltage. Typical tests include:

· Continuity checks – check shorts and/or opens between power and ground
· Supply load test – if the ECU has an analog supply, verify the supply voltage regulation under maximum load condition
· Supply noise test – if the ECU has an analog supply, check noise output level
· Sleep current – check current draw on VBATT with ignition key in Off position
· Wake-up current – check current draw on VBATT with ignition key in On position

Processor

The MPU contains the processor and memory components. In most cases, flash memory is used to store the application software, sometimes referred to as strategy code. The application code includes calibration lookup tables. These tables define the optimum fuel mixture and ignition timing parameters based on feedback from the inputs. With flash memory, you can reprogram the ECU at any time. In some cases, the application code includes a special test mode for manufacturing test. Typical tests include:

· RAM Test – usually some type of pattern write and read
· Flash Test – check manufacturer/part ID, Checksum
· Watchdog Timer Test
· Download Application and/or Embedded Test Code/TCA to Flash

Production test strategies usually involve one or more of the following:

· Application code includes built-in test hooks for external control of the ECU
· Download test code to flash. Test code provides ability to test all inputs and outputs
· Download test-specific code (e.g. download code to read analog inputs only)

Data Link

The ECU has a communications link to the outside world. The number of ECU protocols and standards is large and growing, with new protocols and standards coming out every few years. The communications link serves many functions. One of the most important is to fulfill the onboard diagnostics (OBD) regulatory requirement. OBD facilitates fault detection of vehicle emission systems. The ECU monitors emissions; when they fall out of compliance, it records the data for use by service technicians. Technicians get the data through the communications link and can use other diagnostic tools connected to the communications link to find the faulty part(s). Today’s vehicles typically have more than one ECM (ABS, body control, telematics, etc.) and they are usually tied together through the communications link. The ECU may need status information about nonengine-related electronics or mechanical systems in order to function properly. Similarly, the other ECMs may need status information from the ECU to function properly.

Testing an ECU is often I/O intensive through the communications link. Because communicating to the ECU can use up as much as 30 to 40 percent of actual test time, the device chosen for the communications link can have a huge impact. The throughput latency of the device (e.g. converting RS-232 to CAN and vice versa) can make or break the overall performance of the test system. Depending on the protocol, the choices may be limited; but when choices are available, it is worth the effort to perform benchmarks to find the fastest solution.

A simple example illustrates the impact of your choice. Suppose you have a vehicle communications interface (VCI) device that converts RS-232 to CAN. If the RS-232 side of the VCI device runs at 9600 baud and 1 bit per baud then the transfer rate on the RS-232 side is 9600 b/s (bits per second). A typical message might be formatted as follows:

· Start character
· Source device
· Destination device
· Number of data bytes
· Command byte
· Data bytes – 4 is typical
· End character
· Checksum byte

This is 11 bytes or 88 bits. At 9600 b/s it takes about 9.17 ms to transmit the data. This does not sound like much but it is not unusual to transmit 200 or more messages during an ECU device test. It takes 1.83 seconds just to transmit the data in one direction for 200 messages. Of course, messages usually follow a command/response protocol so the actual time for 200 messages is 2 x 1.83 seconds, or 3.66 seconds. This does not include any other latency involved in converting the data from RS-232 to CAN, from CAN to RS-232, or the processing of the data by either the ECU or the test system controller. You could reduce test time by 1.83 seconds if you can find a VCI device that runs at 18.2 kb/s on the RS-232 side. The effect of choosing a slow device can be even more profound if you must download test code or application code to the ECU.

Discrete Inputs

Discrete (or switch) inputs monitor the on/off status of various components and accessories in an automobile. The most important discrete input is the ignition switch. The ECU needs to know the ignition switch position (start, run, off, accessory) to determine when and how to control the fuel and ignition systems. A few other examples of discrete, or switch inputs are the park switch, brake switch, and A/C switch.


Figure 2. Automotive Switch Input Block Diagram


In an ECU test system, the load/stimulus block, typically consisting of general-purpose and/or matrix relays, connects one of the test resources (VBATT, BATT_GND, DAC, DIO) to the discrete input(s) on the ECU. Typical tests include:

· Walking ones/zeros – For walking ones, set all discrete inputs to low then toggle the inputs from high to low, one at a time. Walking zeros is the inverse.
· Pattern test (e.g. 0xAA, 0x55), read state from ECU
· Connect each input to VBATT, read state from ECU
· Connect each input to BATT_GND, read state from ECU
· Test for open-circuit conditions

Frequency Inputs

Frequency inputs are typically used to monitor sensors that provide velocity (e.g.vehicle speed) or velocity and position (e.g. CRANK) information. The most important feedback signal for an ECU is the CRANK signal. In some engine applications both a CRANK and CAM signal are used to provide speed (rpm) and position (CRANK angle) information to the ECU. The CRANK and CAM sensors can be variable reluctance (VAR) or infrared (IR) sensors. Both types of sensors generate encoder signals that are processed by the ECU to determine fuel and ignition output parameters. Figure 3 shows some typical frequency inputs and the typical waveform characteristics.


Figure 3. Typical Automotive Frequency Inputs and Waveform Characteristics


Typical frequency-input tests include:

· Drive ECU frequency input with signal having varying amplitude and/or frequency and/or duty cycle
· Test for open-circuit condition on input
· Test with VBATT and/or BATT_GND shorted to input

Analog Inputs

The analog inputs monitor the vast array of sensors in an automobile. There are many types of sensors, and each signal is conditioned by the ECU. There are temperature (engine temperature), pressure (MAP – manifold absolute pressure), flow rate (EGR), air quality (O2 – oxygen), and others that are part of the feedback path to the ECU.

Typical analog input tests include:

· Open circuit – no source or load connected to input
· Short to VBATT and/or BATT_GND
· Analog-to-digital conversion linearity (e.g. test with input signal level at 5 and 95% of range)

Switch Outputs

Switch outputs, sometimes called discrete outputs, are typically low current drivers (<2 A). Some examples of switch outputs are signals to control the cruise-control clutch and fuel pump. Switch outputs are sometimes classified as high side or low side drivers depending on whether they provide power (e.g. VBATT) or a ground reference to other components in the system. The loads driven by these outputs are either resistive (e.g. Check Engine lamp) or reactive (e.g. air solenoid).


Figure 4. Automotive Switch Output Block Diagram


Typical tests include:

· Voh = VBATT ±0.5 VDC, Vol = BATT_GND ±0.5 VDC
· Clamp/flyback voltage, usually <100 V
· Output leakage current
· Diagnostics
· Short output to VBATT and/or BATT_GND

Pulse-Width-Modulated (PWM) Outputs

PWM outputs are the most complicated of the ECU outputs. There are other PWM outputs, but the injector and ignition (or EST – engine spark timing) outputs are probably the most computationally intensive. The primary factor that determines the timing, frequency and duty cycle of the injector and ignition outputs is the CRANK speed (rpm) and position (CRANK angle, 0 to 360 deg). There are other factors used to determine the fuel and ignition parameters such as vehicle speed (mph), throttle position (accelerating, decelerating, no change), EGR (exhaust gas recirculation), engine temperature, manifold pressure, fuel temperature/pressure, and many others. In simple terms, the engine strategy code uses all this feedback to perform some calculations and then looks in the calibration table to select the best fuel mixture and spark timing (dwell and spark advance) to optimize engine performance. In general, PWM outputs drive inductive loads such as the ignition coil, and injector solenoid. Most of the loads are less than 5 A; however, some loads such as the ignition coil typically draw from 5 to 20 A, depending on the engine design.


Figure 5. Automotive PWM Output Block Diagram


Typical tests include:

· Voh = VBATT ±0.5 VDC, Vol = BATT_GND ±0.5 VDC
· Clamp/flyback voltage, most <100 V, ignition coil flyback may be up to 450 V
· Output leakage current
· Diagnostics
· Short output to VBATT and/or BATT_GND
· On/off time, rise/fall time, duty cycle, frequency
· Timing/synchronization between CRANK position and injector/ignition/EST (e.g. rising or falling-edge delay time relative to TDC – top dead center)
· Current-versus-voltage level comparison (e.g. Vsat – voltage at I = 500 mA)

Frequency Outputs

Frequency outputs are usually constant frequency and/or duty-cycle outputs. They typically control stepper type devices. An example is the ISC, idle speed control, which adjusts the airflow into the fuel system, which in turn causes the idle rpm to change.

Back to top

National Instruments Virtual Instrumentation


A virtual instrument is a computer-based device that uses digitally controlled data acquisition or signal generation hardware, combined with software algorithms, to create the functionality of an instrument.

With Virtual Instrumentation, one simple, generic instrument can perform the same measurements as many different specialized instruments because the software determines the functionality of the instrument. If you need a new instrument, you write new software or purchase software toolkits with the functionality required.

The PXI platform and Virtual Instrumentation paradigm provide test system developers with the means to achieve the cost and performance benefits required to meet the system design challenges. PXI systems are robust because they are built on industrial computer technology. PXI systems are fast because they use the standard PCI bus architecture. System cost can be managed based on the speed and performance requirements of the application. Controllers are available with different speeds and features that determine cost. Instruments are available with different performance capabilities that determine cost. The PXI architecture and Virtual Instrument paradigm provide a unique ability to protect your hardware and software investment against obsolescence. As more powerful controllers become available, systems can be upgraded by purchasing the more powerful controllers without the need to change the software. Similarly, if higher performance instruments are required, thanks to the Virtual Instrument paradigm, developers can change instruments without changing software. Virtual Instruments provide designers the ability to use one instrument to perform the function of several traditional instruments. All that is required to obtain the necessary functionality is to write software. In some cases, the software functionality may be provided as a standard feature of the development environment, or you may be able to purchase software add-ons that provide the necessary functionality.

Systems that take advantage of the Virtual Instrumentation paradigm provide the ultimate level of flexibility. A/D converters come in many speeds and resolutions. CPU speed is optional. The software is always modifiable. These types of instruments tend to be less expensive than stand-alone instruments because the hardware is simpler and the instruments are designed to use commercially available technology as much as possible, rather than costly custom-designed components for one application.

Back to top

National Instruments Products for ECU Test Applications

Software

Software is a major part of any test system. In the long term, software costs often determine the true cost of a system and may exceed the hardware costs. The hardware is purchased once. Software development tends to be an ongoing activity throughout the life cycle of a test system. Two types of software are usually required:

· Application development environment (ADE) – for writing test code
· Test executive – for managing test sequences

Choosing an ADE is a critical choice that can have a major impact on both long and short-term costs of the system. Test executives can impact cost as well.

ADEs

Every test application requires some type of ADE to create test code. The ADE has a direct impact on development time and therefore a direct impact on the cost of the system. The cost and ease of use of the ADE, as well as the tools and libraries included, need to be considered when selecting an ADE. In addition, the availability of add-ons or software toolkits either from the ADE vendor or third-party software vendors are worth considering. The standard libraries supplied with the ADE and the add-ons available often determine how much code must be written from scratch. In general, the less code a developer has to write, the faster and less expensive is the software development process. National Instruments provides two of the leading software languages in the test and measurement industry.

LabVIEW is one of the leading graphical programming languages in the world. In the LabVIEW programming paradigm, developers can focus more on the application than the ADE. Icons and wires are used to create programs instead of text and syntax. Graphical programming languages speed up the development process. One icon can replace tens or even hundreds of lines of text-based code. LabVIEW provides a point-and-click, drag-and-drop environment with minimal typing compared to text-based languages. Furthermore, LabVIEW is test and measurement focused. Sufficient libraries are included in the ADE to simplify instrument control programming. Many measurement applications only require a few icons wired together to configure a device and make a measurement. In addition to instrument control, LabVIEW provides the necessary data analysis and display libraries for virtually any measurement.

LabWindows/CVI is a text-based programming language designed specifically for test and measurement applications. C is the programming language. Like LabVIEW, LabWindows/CVI is a test and measurement focused ADE. Standard data analysis and display libraries simplify programming tasks. Function panels simplify code creation.

Test Executive

Historically, test code and the test executive were combined. Every time tests for a new product needed to be developed, the developer had to either create a new test executive or port the test executive code from an old product to the new product test code. If changes to the test executive portion of the code were changed because of new product requirements, then every system using that test executive had to change or the new product would need its own version of the test executive. This approach often results in a proliferation of versions of the same test executive, which makes software maintenance and documentation more costly than it needs to be.

Today there are commercial-off-the-shelf (COTS) test executives. With COTS test executives, test system developers focus on the test code rather than worry about the test executive. National Instruments TestStand is considered one of the best COTS test executives on the market. TestStand is full-featured test executive software that can interface with test code developed in virtually any ADE. This feature is derived from the ability of TestStand to link to a DLL. TestStand provides tight integration with code generated using National Instruments LabVIEW and LabWindows/CVI.

Vehicle Communications Interfaces

National Instruments provides CAN (controller area network) devices for many platforms – PCI, PXI and PCMCIA. These devices can be used in virtually any automotive test application that requires a CAN interface.

Digital Multimeters

As shown in Table 1, National Instruments provides three multimeters suitable for ECU tests.

Model
Bus
Accuracy
Modes
Ranges
Autozero
Triggering for Scanners
PCMCIA
5.5 digit
Resistance
(2-wire only), Current, Voltage, Diode
Res: 200 Ω to 2 MΩ; Current: 20 mA to 10 A; Volts: 20 mV to 250 VAC
no
no
NI 4060
PCI, PXI
5.5 digits
Resistance (2 and 4-wire), Current, Voltage, Diode
Res: 200 Ω to 2 MΩ; Current: 20 mA to 10 A; Volts: 20 mV to 250 VAC
yes
yes
PCI, PXI
6.5 digits
Resistance (2 and 4-wire), Current, Voltage, Diode, Digitizer
Res: 100 Ω to 100 MΩ; Current 20mA to 10 A; Volts: 100mV to 300V
yes
yes

Table 1. NI Multimeters Applicable in Automotive Applications


The NI PCMCIA-4050 could be used for applications where size and portability are the primary considerations, such as bench-top, in-vehicle, and service bay test systems. NI 4060 and NI 4070 devices are more appropriate for R&D and production test systems.

NI 4070 devices are fast and accurate 6.5-digit DMMs that includes a digitizer mode. In the digitizer mode, you can measure high-voltage waveforms without the need for additional signal conditioning.

Multifunction Input and Output

Table 2 below lists some Multifunction Data Acquisition devices that can be used to test an ECU. MIO devices provide both signal measurement and generation capabilities. In general, ECU tests can be considered low frequency, although some tests do require high resolution in the time domain (e.g. flyback pulses less than 10-20 µs wide). If an ECU test application does not require high-resolution measurements, then lower speed and lower cost devices are available. Because most ECU test applications do require these types of tests, it is unlikely that sample rates less than 500 kS/s will be satisfactory.

DAQ Device
Bus
AI
AO
Sample Rate
Bits
Range
DIO
TC
Triggers
PCMCIA
16
2
500 kS/s
12
AI: ±10 V;
AO: ±10 V
8
2, 24 bit
analog, digital
NI 6070E
PXI, PCI
16
2
1.25 MS/s
12
AI: ±10 V;
AO: ±10 V
8
2, 24 bit
analog, digital
FireWire
16
2
1.25 MS/s
12
AI: ±10 V;
AO: ±10 V
8
2, 24 bit
analog, digital
NI 6071E
PXI, PCI
64
2
1.25 MS/s
12
AI: ±10 V;
AO: ±10 V
8
2, 24 bit
analog, digital
PXI, PCI
4
2
AI: 10 MS/s
AO: 4 MS/s
12
AI: ±42 V;
AO: ±10 V
8
2, 24 bit
analog, digital

Table 2. NI Multifunction DAQ Devices Applicable in Automotive Applications


The DAQCard-6062E (PCMCIA) and DAQPad-6070E (FireWire) can be used in applications where size and portability are primary considerations. Both devices have sufficiently high sampling rates to make any measurement required. Typical applications for these devices would be bench-top, in-vehicle, and service bay test systems.

The NI 6070E, NI 6071E and NI 6115E for PCI and PXI can be used in any of the possible ECU test applications but are most appropriate for R&D and production test applications.

MIO devices are a cost-effective solution for ATE applications that require both signal generation and measurement capability. The NI PXI-6115 is a particularly good option for ECU test applications. The ±42 V input range and high-speed simultaneous-sampling capability of the PXI-6115 gives developers an instrument capable of making the timing and synchronization measurements that are usually required.

As can be seen in Table 2, the input ranges of most of the MIO devices requires signal conditioning to measure voltages greater than 10 V. A 10:1 attenuator will suffice for most signals except the ignition coil flyback (or clamp) voltage test. In-vehicle test systems may require filtering, such as a lowpass filter, to eliminate ignition noise.

Sources

Static Voltage and Current Output

Table 3 lists some options for static analog output sources. The analog inputs for an ECU typically require a voltage source between VBATT and BATT_GND or between V_ANALOG and A_GND. Many methods are used to provide the stimulus necessary to test the analog input of an ECU. One method that maximizes hardware reuse and reduces fixturing costs is using a digital-to-analog converter (analog output) source device. With such devices, you can provide a programmable voltage to the analog inputs of the ECU. In the case of sources that have multiple isolated outputs, you can cascade the outputs to increase the voltage and/or current source capability.

Family
Bus
Outputs
Bits
Output Rate
Range
DIO
Counter/Timers
Current Sinks
Triggers
NI 6704
PCI, PXI
16 voltage, 16 current
16
-
±10 V, 0 to 20 mA
8
-
yes
-
NI PCI-6703
PCI
16 voltage
16
-
±10 V
8
-
-
-
DAQCard-AO-2DC
PCMCIA
2 voltage, 2 current
12
-
±5 V,
±10 V,
0 to 20 mA
8
-
yes
-
SCXI
6 voltage or current
12
-
±10 V, 0 to 20 mA
-
-
yes
-

Table 3. NI Analog Output Devices Applicable in Automotive Applications


As an example, the SCXI-1124 has six isolated ±10 V outputs. The six outputs can be daisy chained to provide a 60 V source. This type of device can be used to back-drive the outputs of the ECU to verify clamp voltages or output current leakage.

Arbitrary Waveform Generators

Table 4 shows an arbitrary waveform generator that could be used to generate any of the waveforms required to test the frequency inputs on the ECU. The arbitrary waveform generator could also be used to provide the static DC voltages required to test the analog inputs on the ECU.


Product
Bus
Channels
Update Rate
Frequency Range
Resolution
Ranges
NI 5411
PCI, PXI
1
40 MS/s
16 MHz
12 bits
±5 V into 50 Ω or 10 V into high impedance

Table 4. NI Arbitrary Waveform Generators


National Instruments MIO devices can perform arbitrary waveform generation also. Depending on the application and the instrument set required, a separate device for waveform generation may not be required.

Digital Input and Output

Table 5 lists some options for digital input and output (DIO), some with isolation. Many production test systems require DIO for purposes other than testing the ECU, such as for fixture control (e.g. solenoids in pneumatic fixtures), communications with other process equipment (e.g. robots, SMEMA Interface), equipment status indicators (e.g. red, green, and amber light tree), and high-current load relays.

Family
Bus
DIO Lines
SSR
Max. Rate
Onboard Memory
Ranges
Isolation
Triggers
NI 6527E
PXI, PCI
24 input,
24 output
-
Static I/O
-
28 V input,
60 V output
yes
-
SCXI-1162HV
SCXI
32 input
-
Static I/O
-
±240 VAC
yes
-
SCXI
-
32 output
Static I/O
-
-
yes
-

Table 5. NI Digital I/O Devices Applicable in Automotive Applications


Depending on test requirements, isolated DIO can be used to provide the load or stimulus for switch outputs or discrete inputs.

Switching

Table 6 lists some National Instruments switches that can be used for automotive test applications.

Product
Bus
Topology
Channels
Max Voltage
Max. Switching Capacity
Bandwidth
SCXI
Matrix and Multiplexer
4x8 (2-wire);
32x1 (2-wire)
±250 VDC,
250 Vrms
1 A @ 30 VDC,
500mA @125 Vrms,
200 mA @250 Vrms
11 MHz
SCXI
Matrix
256 crosspoints (2-wire)
±150 VDC,
150 Vrms
1 A @ 150 VDC,
250 mA @150 Vrms
10 MHz
PXII
Matrix
128 crosspoints (2-wire)
±150 VDC,
150 Vrms
1 A @ 150 VDC,
250 mA @150 Vrms
10 MHz
SCXI
Matrix and
Multiplexer
256x1 (1-wire)
128x1 (2-wire)
64x1 (4-wire)
4x64 (2-wire)
4x32 (1-wire)
8x32 (1-wire)
±60 VDC,
30 Vrms
0.4 A, 10 W
15 MHz
PXI
Matrix and
Multiplexer
128x1 (1-wire)
64x1 (2-wire)
32x1 (4-wire)
4x32 (1-wire)
4x16 (1-wire)
8x16 (1-wire)
±60 VDC,
30 Vrms
0.4 A, 10 W
15 MHz
SCXI
General-Purpose
32 SPDT
±150 VDC,
125 Vrms
2 A, 60 W, 62.5 VA
70 MHz
PXI
General-Purpose
16 SPDT
±150 VDC,
125 Vrms
2 A, 60 W, 62.5 VA
70 MHz
SCXI
PXI
Relay Driver
64 Channels SPST
±50 VDC,
600 mA
N/A
SCXI
General-Purpose
16 SPDT
±250 VDC,
250 Vrms
2 A @30 VDC,
2 A @250 Vrms
10 MHz
SCXI
General-Purpose
8 SPST
±250 VDC,
250 Vrms
5 A @30 VDC,
8 A @125 Vrms
10 MHz
PXI
Matrix and Multiplexer
4x6 (2-wire);
24x1 (2-wire)
±60 VDC,
30 Vrms
1 A @30 VDC
10 MHz
PXI
General-Purpose
16 SPST
±125 VDC,
250 Vrms
5 A @30 VDC,
7 A @250 Vrms
10 MHz

Table 6. NI Switches Applicable in Automotive Applications


National Instruments provides terminal block accessories for the SCXI-1127 and SCXI-1129 so system designers can use several modules to expand the matrix configuration options. As an example, the SCXI-1129 can be used with the SCXI-1335 terminal block to create one 8x32 matrix. You can combine two SCXI-1129s and two SCXI-1335s to create an 8x64 matrix by connecting the rows of the two switch modules together.

Signal Conditioning

Oftentimes, ECU test systems require signal conditioning. Signal attenuation, filtering, and amplification are probably the most common types of signal conditioning required. National Instruments can provide some of the signal conditioning required.

PWM outputs are usually connected to inductive loads. A high-voltage flyback pulse is usually generated whenever the output is turned off. Except for the ignition coil outputs, these flyback voltages are usually less than 100 V. A 10:1 attenuator typically provides sufficient attenuation for measurement of these flyback voltages by computer-based instruments. The National Instruments SCC-A10 provides a differential 10:1 attenuator that will extend the range of the analog input device used to measure these high voltages.

Because frequency inputs on the ECU sometimes require voltages beyond the range of the analog output or arbitrary waveform generator, an amplifier may be required to boost the voltage to the amplitude required. Some ECU designs provide power to the frequency input sensor in the form of a pull-up resistor. In these cases the output of the signal generator may need to be converted to an open-collector output. Frequency inputs on the ECU are sometimes differential. The signal generator output may need to be converted from a single-ended output to a differential output.

In some cases, system noise can be a problem and degrade the reliability and repeatability of measurements. This usually calls for some type of noise filter, such as a lowpass filter, to eliminate noise.

Back to top

Conclusion


ECUs are complex electronic devices with multifunction inputs and outputs. Test engineers are faced with many challenges in designing and developing systems to test these devices. Computer-based instrumentation, such as PXI, combined with the virtual instrumentation paradigm provides system developers the hardware and software platforms necessary to meet the challenges of ECU test applications today and in the future.

Back to top