Professional Documents
Culture Documents
ECU Designing and Testing Using National Instruments Products
ECU Designing and Testing Using National Instruments Products
National Instruments has various products that can be used for various applications in Automotive Industries. Using NI Products
you can design and test ECU's and other Automotive electronics components. This document talks about ECU's and the various
protocols that are typically used in the Automotive Industry. It also describes the various options that NI offers to do ECU design
and testing.
Table of Contents
1.
2.
3.
4.
5.
Introduction
Different Types of ECU's
Typical Inputs/Outputs of an ECU
Different types of Protocols used
Design and Testing
1. Introduction
In the Automobile industry an electronic control unit (ECU) is a embedded electronic device, basically a digital computer, that read
signals coming from sensors placed at various parts and in different components of the car and depending on this information
controls various important units e.g. engine and automated operations within the car and also keeps a check on the performance
of some key components used in the car.
An ECU is basically made up of hardware and software (firmware). The hardware is basically made up of various electronic
components on a PCB. The most important of these components is a microcontroller chip along with an EPROM or a Flash
memory chip. The software (firmware) is a set of lower-level codes that runs in the microcontroller.
The ECU is characterized by:
many analog and digital I/O lines (low and high power)
power device interface/control
different communication protocols (CAN, KWP-2000, etc.).
large switching matrices for both low and high power signals
high voltage tests
intelligent communication interface adapters (standard or custom)
automatic fixture recognition and software sequence enable
power device simulation
2. Different Types of ECU's
Depending on what it is used for ECU's are named and differentiated as below :
ECM Engine Control Module. (Many a times in the industry ECM are called as ECU - Engine Control Unit).
The ECM also known as EMS (Engine management system) is an ECU in an internal combustion engine that controls various
engine functions like fuel injection, ignition timing and idle speed control system. All these control are done based on data (like
engine coolant temperature, air flow, crank position etc) received from various sensors.
The ECMs also learns about the engine as we drive our car. The "learning" is actually a process that the ECU uses to track the
tolerance changes of the sensors and actuators on the engine. For examples the idle-air bypass valve (automatic choke) at idle
with the A/C in the CAR on and off. The ECM stores these "learned" values in battery backed-up RAM so that it doesn't have to
start from scratch the next time the engine is turned over. A detail discussions on ECMs are done in the later part of the paper.
With the enforcement of the Federal Emission Regulations in 1981 ECUs are being used popularly in most of the vehicles. In the
aeronautical applications these systems are popularly called as FADECs (Full Authority Digital Engine Control).
EBCM Electronic Brake control module.
1/9
www.ni.com
1. The Brake: This input give the status of the brake pedal i.e. deflection or assertion. This information is acquired in a digital or
analog format.
2. The 4 W.D: This input gives the status in digital format whether the vehicle is in the 4-wheel-drivemode.
3. The Ignition: This input registers if the ignition key is in place, and if the engine is running or not.
4. Vehicle Speed: This input gives the information about the speed of the vehicle.
5. Wheel speed: In a typical application this will represent a set of 4 input signals that convey the information concerning the speed
of each wheel. This information is used to derive all
necessary information for the control algorithm
PCM Powertrain control module.
PCM is an ECU that monitors and controls speed control, A/C, charging and Automatic Transmission. The inputs that are fed to
the PCM are from:
throttle position sensor,
output shaft speed sensor,
vehicle speed sensor
engine speed sensor (CKP)
brake switch
cruise control switches
ignition
overdrive on/off switch
governor pressure sensor.
Using these inputs it does transmission control, valve control through PWM outputs, torque converter clutch and transmission
protection relay control and provides the feedback to the driver through the dashboard overdrive lamp.
www.ni.com
Yaw rate sensors, Lateral acceleration sensors to provide an output to the ESC for the safest driving experience.
BCM Body control module.
BCM is an ECU that takes care of seating control unit, wiper control, power windows and power hoods in convertible cars (e.g.
Benz SL Roadster).
3. Typical Inputs/Outputs of an ECU
Let us have a look at some of the most typical kind of sensors and actuators that are connected to an Engine control module and
what kind of I/Os do they require.
Manifold Air temperature Sensor (MAT)
The sensor is a thermistor. It is normally mounted at the air duct housing of the manifold. Electrical resistance of the thermistor
decreases in response to the temperature rise and this can be measured using analog channel with some signal conditioning.
(excitation, amplification etc.)
Coolant Temperature Sensor (CTS)
The CTS too uses a thermistor to detect the temperature of the coolant in the engine and feeds the voltage signal to an analog
input channel of the ECM.
Camshaft/Crankshaft Position Sensor (CPS)
The CPS is very important as it monitors the engine speed and the piston position in the engine. Traditionally variable reluctance
sensors were used to measure this but nowadays various IR sensors and latest rotary encoders are used to do the same. These
encoder signals are provided as frequency inputs to the ECUs.
Knock Sensor (KS)
The KS is a typical piezoelectric sensor, it picks up the knocking vibration from the cylinder block where it is fixed and this
complex/dynamic analog signal is fed to the ECU.
Heated Oxygen Sensor (HO2S)
The HO2S is an air quality measurement sensor. The sensor is basically made of ceramic zirconia which is placed in the exhaust
manifold enclosed in a closed tube. The zirconia generates voltage from approximately 1V Max in richer conditions to 0V in leaner
conditions. This analog signal is passed on to the ECM.
Throttle Position Sensor (TPS)
The TPS is a potentiometer that transforms the throttle position into output voltage which is fed to the ECM.
3/9
www.ni.com
The TPS is a potentiometer that transforms the throttle position into output voltage which is fed to the ECM.
Vehicle Speed Sensor (VSS)
The VSS is placed on the transaxle. It is a pulse generator and provides a digital signal to the ECM.
Manifold Absolute Pressure (MAP)
The Manifold Absolute Pressure sensor measures changes in the intake manifold pressure resulting from engine load and speed
changes. The ECM sends a 5-volt reference signal to the MAP sensor. As pressure changes in the intake manifold occurs, the
electrical resistance of the MAP sensor also changes. By monitoring the sensor output voltage, the computer can determine the
manifold absolute pressure. The higher the MAP voltage output the lower the engine vacuum, which requires more fuel. The lower
the MAP voltage output the higher the engine vacuum, which requires less fuel. Under certain conditions, the MAP sensor is also
used to measure barometric pressure. This allows the computer to automatically adjust for different altitudes. The computer uses
the MAP sensor to control fuel delivery and ignition timing.
These are some of the most important signals that the ECM takes to control the fuel injection system in an efficient way for proper
fuel management.
The NI hardware that can be used with these sensors can be chosen from the list given below:
ODBII protocol This is a one of the most popularly used standard introduced in the mid 90s and takes care of the complete
engine control and monitoring of the chassis and the accessories. It is used by almost all
the automakers
CAN ISO 11898 Another very popular protocol used by almost all the automaker for on-board diagnostics. The pin details are as
below.
Pin 2 - J1850 Bus+
Pin 4 - Chassis Ground
Pin 5 - Signal Ground
Pin 6 - CAN High (J-2284)
Pin 7 - ISO 9141-2 K Line
Pin 10 - J1850 Bus
Pin 14 - CAN Low (J-2284)
Pin 15 - ISO 9141-2 L Line
4/9
www.ni.com
The traditional way to develop automotive embedded systems has been to build hardware boards that represent all or part of each
ECU and part of its surroundings, often called plant models, and use them for bench testing. Unfortunately, the bench approach
has many limitations.
First, creating all the needed hardware boards is costly.
Second, the performance requirements of the most powerful ECUs (those used for Powertrain control) are so demanding that it is
no longer possible to build boards that allow adequate measurements to be taken.
Finally, and most importantly, this bench testing approach is based on a sequential design process where hardware is developed,
plant model prototypes are built and software development begins.
To overcome these limitations control design engineers have adopted a highly efficient design process often referred to as the V
diagram. Though originally developed to encapsulate the design process of software applications, many different versions of this
diagram can be found to describe different product design cycles. The one given below is typically what is used in ECU design
cycle.
5/9
www.ni.com
In this diagram the general progression of time in the development stages is shown from left to right. However, this is often an
iterative process, and the actual development will not proceed linearly through these steps. Instead, you will spend time in each
step and even have to backtrack from time to time. The goal is to make this cycle as efficient as possible by minimizing the
amount of backtracking between steps as well as the time spent in each step.
The y-axis of this diagram can be thought of as the level at which the system components are considered. Early on in the
development, the requirements of the overall system must be considered. As the system is divided into sub-systems and
components, the process becomes very low-level down to the point of loading code onto individual processors.
Afterwards, components are integrated and tested together until such time that the entire system can enter final production testing.
Therefore the top of the diagram represents the high-level system view and the bottom of the diagram represents a very low-level
view.
Lets have a look into these steps one-by-one.
System Definition.
In this step initially the design engineers documents the needs and requirements of the project using spreadsheet or word
processing applications. The documentation also takes care about the various specification of the engine and the various norms it
needs to comply with. It also marks the limit levels of the parameters involved in controlling the engine.
Once the specifications are documented the actual design process begins in which first a software model of the ECU and the
engine is built.
And once the models are build the third step involves software-in-the-loop simulation. In this step both the software models; ECU
model and Engine model; are connected together in a closed feedback loop and then simulated to analyze the dynamic
characteristics of the entire system. During the simulation the ECU model monitors the output from the Engine model and adjusts
the inputs to the Engine model in order to improve the performance of various engine functions like fuel injection, ignition etc.
National Instruments provides three options for building a software model.
6/9
www.ni.com
7/9
www.ni.com
The software that would be required is LabVIEW , LV RT and LV FPGA (if using cRIO or 7831R in PXI). If the model is build in
MATRIXx then a dll can be created out of it and imported into LabVIEW where the I/O interface can be provided and the code can
be downloaded into one of the Real-Time Hardware targets mentioned above. If its a Simulink model then after being imported
or translated into LabVIEW the I/O interface can be provided to the same and then target to the RT Hardware like PXI or cRIO
As mentioned in the Input Output section appropriate hardwares can be used in the PXI or cRIO depending on the parameters
being controlled and the sensors being used.
Targeting
In this step the core ECU model is modified to interface with the I/O available in the actual ECU and then is converted into a C
code using a C code generator. In some cases they are also converted into an ada code. And then this code is downloaded as
the control algorithm to the 32-bit microcontroller inside the ECU.
Currently LabVIEW doesnt have the capability or tools to convert the block diagram into a C code. Thus those who are using NI
Control design bundle to build the model of the ECU has to hand code the model in C. Though it is tedious to do this than using
8/9
www.ni.com
Control design bundle to build the model of the ECU has to hand code the model in C. Though it is tedious to do this than using
an auto C code generator many customers prefer to do this as in most cases the C code generator creates a lot of errors in the
code generated which is very difficult to debug.
Anyway if the customer is using MATRIXx to build the model than we have a product called AUTOCODE which can generate a C
code or an ada code from the SystemBuild model that was build for the ECU.
Hardware-in-the-loop Simulation (HIL)
Once the code containing the control algorithm is downloaded to the ECU we can test the performance of the ECU under extreme
conditions, which cannot be achieved in real world, by performing HIL simulation. In this step the actual ECU is tested by
simulating an engine using the Engine model that we had created earlier.
In vice-versa to what we did in RCP, here in HIL the software model of the Engine is downloaded to a Real-Time hardware and the
appropriate I/O interfaces are provided. These I/O are then connected to the actual ECU. Then various engine conditions can be
simulated and the ECU can be tested to its limits which wouldnt be possible if it was tested using an actual Engine.
.
Again like RCP the hardware for the HIL is decided according to the signals and the sensors that we are going to simulate, this
can be chosen from the list given in the Input/Output section
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. Other product and company names listed are
trademarks and trade names of their respective companies.
9/9
www.ni.com