ECU Designing and Testing Using NI Products

ECU Designing and Testing using National Instruments Products Publish Date: Nov 07, 2009

Overview 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. Introduction 2. Different Types of ECU's 3. Typical Inputs/Outputs of an ECU 4. Different types of Protocols used 5. 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 ECM’s 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 ECM’s are done in the later part of the paper. With the enforcement of the Federal Emission Regulations in 1981 ECU’s 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. This is an ECU that is used in the ABS (anti-lock braking system) module of a car. They were introduced in the early 1970’s to improve vehicle braking irrespective of the road and whether conditions. Though its very recently that it started gaining popularity. The EBCM regulates the braking systems on the basis of five inputs that it receives.

1/6

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.

VCM – Vehicle control module VCM is an ECU that takes care of systems like: · Electronic Powersteering (EPS) systems · Adaptive Cruise control (ACC) systems · Airbag control system (ACS) systems. · Electronic Stability Control (ESC) systems. The VCM is typically installed in the middle of the car between the passenger and the engine compartment. They are connected to various kinds of sensors to control various systems in the car. They take inputs from crash sensors (micro-machined accelerometers) and sensors that detect occupant weight, seating position, seat belt use and seat position to determine the force with which the frontal air bags should deploy. Similarly they take inputs from Steering wheel angle sensors, Wheel speed sensors, 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 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) And typically in an Engine Control Unit there are many kinds of sensors and actuators connected and its very important to know the kind of I/O they require.

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/O’s 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 ECU’s.

2/6

www.ni.com

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. 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:

4. Different types of Protocols used Automobile protocols can be broken down into following major categories. ·Diagnostics On-board diagnostics are into existence from the early 1980’s. But in the recent years they have become highly sophisticated. Thus there are highly reliable protocols just used for on-board diagnostics. Some of the most frequently used once are:

ODBII protocol – This is a one of the most popularly used standard introduced in the mid 90’s 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 Pin 16 - Battery Power Keyword 2000 and J1850 – These protocols are basically used by GM, Chrysler for on-board diagnostics. J1850 is a very old protocol and is being phased out.

·Body and Powertrain Body and Powertrain networks may consist of CAN, LIN, or J1850 protocols. CAN is versatile protocol and is majorly used in various categories of in-vehicle networks. High speed CAN is often used for Powertrain applications such as engine timing to ensure that the car runs efficiently. LIN -- Local Interconnect Network (LIN) is a UART based network that was developed strictly for body applications. For example, a LIN network connects all of the electric devices in a car door. LIN and CAN may coexist. It is majorly used by Chrysler, BMW and Volkswagen.

·Multimedia and Drive by wire

3/6

www.ni.com

MOST -- It is a fiber optic network that has been optimized for use in the automobile. It is designed for use with simple devices such as microphones and speakers along with more complex devices such as security devices such as those used to locate stolen automobiles. MOST technology is being developed and promoted by a Cooperation, which includes BMW, Daimler-Chrysler, and Audi. IDB 1394 -- It is the latest addition to the IDB family of in-vehicle networks, designed for high speed multimedia applications that require large amounts of information to be moved quickly on a vehicle. Previously known as IDB-M, IDB-1394 is built on IEEE-1394 technology that has already gained wide acceptance in the consumer electronics community. The IDB-1394 specification defines the automotive grade physical layers (e.g. cables, connectors), power modes, and the higher layer protocols needed to assure interoperability of all IDB-1394 devices. Drive by wire protocols have not been fully developed at this point. There is also some disagreement about which protocol will become the industry standard. While Flexray offers high speed, it is expensive and further away from standardization. FlexRay -- It is a scalable, flexible high-speed communication system, which meets the increasing technical demands in the automobile industry. With its data rate of up to 10 MBits/s, it is ideal for Xby wire applications.

5. Design and Testing 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 ECU’s (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.

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.

4/6

www.ni.com

1st Option --- LabVIEW. LabVIEW with the Control Design and Simulation Bundle provides a very good platform to design and model the Engine and the Engine control unit. The Control Design and Simulation bundle basically consists of three toolkit for this purpose. System Identification Toolkit and Control Design Toolkit :- This toolkit contains various System Identification VI’s that helps to build mathematical models of the dynamical systems of an engine. These models can then be integrated together to generate a complete model of the engine which using the control design VI’s can be analyzed and used to design the mathematical model of the ECU. Simulation Module:- The simulation module provides a simulation environment within LabVIEW. Customers can also build the engine and the ECU models in block diagram form (like Simulink® models) using the various VI’s available in LabVIEW for logical and arithmetic functions, signal processing, filtering etc. along with Dynamical elements, look-up tables etc provided by the simulation module. After the model is designed Software-in-the-loop simulation can be done using the same simulation environment. The documentation for the model can be prepared using any word or spreadsheet application.

2nd Option --- MATRIXx MATRIXx has similar capabilities to Matlab®/Simulink®. It is ideal tool for customers who are planning to build their models from scratch and are looking for tools that can accomplish very complex control design application and simulate it at high speed. MATRIXx is basically made of four products:1) XMath 2) SystemBuild 3) AUTOCODE 4) DocumentIt Using XMath and SystemBuild software, customers can model their ECU’s and Engines and then using these models can perform Software-in-the-loop simulation. XMath software is a basic analysis and visualization software environment that controls SystemBuild and all related MATRIXx environment. It also helps in handling data and performing numerical analysis for SystemBuild. SystemBuild is a graphical programming environment that can be used to model and simulate the Engine and the ECU system. It has a choice of over 80 block types that can be used to build complex Engine and ECU models. For documenting the model MATRIXx has a product called DocumentIt which will auto create documents in various formats from the models build in SystemBuild. 3rd Option --- LabVIEW + Simulink® If you have a ready-made engine model built in Simulink® and wouldn’t like to rework/rebuilt the model. Then there are two options available: 1) Using Simulation Module we can translate the existing Simulink® model (.mdl file) into a LabVIEW block diagram code which can be done very easily in a three step process. 2) Simulation Interface Toolkit (SIT) is a LabVIEW add-on that provides tools to create LabVIEW interface to communicate successfully with an existing Simulink® model. a) Communicate directly between LabVIEW and the Simulink® model. The SIT Server needs to be started from MATLAB® to allow this communication. The Simulink® model can also be running on the host PC or another different PC.

The documentation can be done by using any word or spreadsheet application. b.) Run the model on a Real-Time system by converting the Simulink® model to a DLL. Once the DLL is built, neither SIT Server nor the model is needed.

Rapid Control Prototyping

5/6

www.ni.com

Rapid Control Prototyping It is also called as Engine-in-the-loop Simulation (EIL). We shouldn’t confuse this with the term rapid prototyping (RP) which refers to a class of technologies that can automatically construct physical models from Computer-Aided Design (CAD) data. For RCP, the software ECU model that has been designed is downloaded to a Real-time Hardware prototype target. The Target can be any Real-time hardware (ideally a PXI system or a cRIO system).Thus the software model of the ECU is given I/O interface which is in turn connected to sensors and actuators attached to the engine.

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 it’s 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 doesn’t 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 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 wouldn’t 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.

6/6

www.ni.com