400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel: (724) 776-4841 Fax: (724) 776-5760 Web: www.sae.org

SAE TECHNICALPAPER SERIES 2004-01-1724

Testing Networked ECUs ina Virtual Car Environment

M. Plöger, J. Sauer, M. Büdenbender and J. HelddSPACE GmbH, Germany

F. Costanzo, M. De Manes, G. Di Mare, F. Ferrara and A. MontieriELASIS, Italy

Reprinted From: Testing and Instrumentation 2004(SP-1871)

2004 SAE World CongressDetroit, MichiganMarch 8-11, 2004

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, ortransmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,without the prior written permission of SAE.

For permission and licensing requests contact:

SAE Permissions400 Commonwealth DriveWarrendale, PA 15096-0001-USAEmail: permissions@sae.orgFax: 724-772-4891Tel: 724-772-4028

For multiple print copies contact:

SAE Customer ServiceTel: 877-606-7323 (inside USA and Canada)Tel: 724-776-4970 (outside USA)Fax: 724-776-1615Email: CustomerService@sae.org

ISBN 0-7680-1319-4Copyright © 2004 SAE International

Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE.The author is solely responsible for the content of the paper. A process is available by which discussionswill be printed with the paper if it is published in SAE Transactions.

Persons wishing to submit papers to be considered for presentation or publication by SAE should send themanuscript or a 300 word abstract of a proposed manuscript to: Secretary, Engineering Meetings Board, SAE.

Printed in USA

2004-01-1724

Testing Networked ECUs in a Virtual Car Environment

M. Plöger, J. Sauer, M. Büdenbender and J. Held dSPACE GmbH, Paderborn, Germany

ELASIS, Naples, Italy

ABSTRACT

Modern vehicles use electronic control units (ECUs) to perform their functions. The ECUs are becoming more powerful and more complex in terms of their functionality. Moreover, many functions are distributed across several interconnected ECUs. It is this interconnection via data bus (CAN) that enables sensors, calculated information and actuators to be shared. ECU manufacturers eliminate many errors during the project and testing phases of a single ECU, but many others are very difficult to detect without performing testing at integration and system level. This paper describes a concept and a powerful tool, VirtualCar, which allows a wide range of automatic tests to be performed on networked ECUs. The VirtualCar tool presented is based on hardware-in-the-loop (HIL) technology from dSPACE. It was designed and realized in a joint project by ELASIS, a FIAT-owned engineering company; dSPACE GmbH, Germany; and TESIS GmbH, Germany. More precisely, it represents a complex system for connecting and testing all the networked ECUs in a modern car of the compact class. This involves more than twenty ECUs divided into two separate CAN networks. INTRODUCTION

For many years, the development of new vehicles has been characterized by the ever increasing use of electronic control units (ECUs). As legislation on environmental protection is repeatedly stiffened, e.g., CARB’s OBD II standard, EOBD in Europe, mandatory reduction of fuel consumption, more and more complex engine controllers are required. Automatic gearboxes with new transmission concepts are also being increasingly used in medium-sized and compact cars. Electronic systems from the field of vehicle dynamics (ABS, ESP, ASR) are very often standard equipment in modern cars. Even for car body and convenience, ECUs have become indispensable.

Thus many functions, e.g., seat movement, side view mirror movement, interior/exterior illumination, parking assistant and dashboard, are realized by means of ECUs. Implementing these complex functions is feasible only if the control units are interconnected via busses. This data bus networking of ECUs in the vehicle enables the sensor system, computed data, and the actuator system to be used jointly by a variety of functions. Typically, modern vehicle concepts consist of two or three different CAN networks. Particular ECUs, connected to more than one network, serve as gateways between the networks in these configurations. Figure 1 shows the network system of a Fiat Stilo, a current representative of the compact car class.

Figure 1: Electronic architecture of the Fiat Stilo

F. Costanzo, M. De Manes, G. Di Mare, F. Ferrara and A. Montieri

Copyright © 2004 SAE International

The Fiat Stilo vehicle contains the following ECUs:

• NBC: Body Computer Node

• NPG: Driver Door Node

• NPP: Passenger Door Node

• NSP: Parking Sensor Node

• NPE: Passive Entry Node

• NAG: Driver Seat Node

• NAP: Passenger Seat Node

• NBS: Steering Column Lock Node

• NVO: Steering Wheel Node

• NQS: Dashboard Node

• NIT/NRR: Infotainment Node/Receiver Node

• NAC: Adaptive Cruise Control Node

• NVB: Trunk Node

• NCL: Air Conditioning Node

• NAS: Steering Wheel Angle Sensor Node

• NGE: Electric Power Steering Node

• NFR: Brakes Node [VDC, ABS, ASR]

• NCM: Engine Control Node

• NCA/NCR: Automatic Transmission Node

/Selespeed Transmission Node

• NSC: Gear Selector Node

• CAV: Alarm Sensor / Roof Unit Control

• CSP: Rain / Sun Sensor Unit Control

• DEV: External Light Commands

• CSA: Alarm Unit Control

• CPP: Tyre Pressure Unit Control

• CAB: Air-Bag Unit Control

• CPS: Left Headlight Unit Control

• CPD: Right Headlight Unit Control

The ECUs have CAN controllers (nodes) and are distributed on two CAN networks. The low-speed CAN network, the B-CAN, is connected to all body and comfort ECUs. The powertrain and vehicle dynamics ECUs are connected to the high-speed C-CAN bus. The body computer forms the gateway between the two CAN networks. ECU manufacturers eliminate many errors during the project and development phases of the single ECUs. One of the standard tools, which has been widely used for years, is hardware-in-the-loop technology. This

particularly applies to all powertrain and vehicle dynamics ECUs. However, there are many other errors which cannot be detected without performing tests at integration and system level. This means that the complete system of networked ECUs must be tested. This task is typically performed at the OEM or, as in this case, at an engineering company (ELASIS) working for the OEM (Fiat).

TESTING ECU NETWORKS

CONVENTIONAL TEST METHODS

Before the first vehicles prototypes are available, tests on ECUs (hardware and software) and other electrical components are performed on �static� benches that comprise the networked ECUs, the actual wiring harness and some of the sensors and actuators, i.e., the dashboard, the electrical motors of the seats, the control switches, etc. These benches (see Figure 2) are normally used to test electrical actuators, simple sensors, and wiring harness, and to perform functional tests on the car body electronics and the self-diagnosis software. The network management, gateway functionality and CAN physical level are also tested. In order to perform these tests, breakout boxes are added to introduce electrical faults, power supplies are used to generate ground shift presence, and some tools for CAN network and diagnostic lines analyses are used. During vehicle development, the individual components are gradually replaced by prototypes that have previously undergone thorough testing. Tests are performed manually, so they are not fully reproducible and automatic test report generation is not possible. Finally, on the static bench it is not possible to have complete test coverage because plausibility conditions are not simulated, especially for powertrain and chassis systems.

Figure 2: Conventional ECU test bench

The testing of networked ECUs addresses a specific set of questions which cannot be answered well enough by conventional test methods:

• Has CAN communication been implemented correctly by all the ECU manufacturers?

• Do the ECUs detect errors in CAN communication properly and does the resulting ECU behavior comply with the OEM’s specification?

• Does the network management work correctly in all the ECUs? Do all the ECUs enter sleep modes as specified?

• Do the ECUs make their sensor signals available to other ECUs via the CAN bus fast enough?

• Does the gateway between different subnetworks work correctly?

• How fast do actuators, driven by their ECUs, react to demands from other ECUs via CAN?

• Do the on-board diagnostic functions work as required?

A number of requirements for the HIL test system can be derived from these questions. The user’s requirements for the VirtualCar test system are described below. They are fairly representative of other test systems for networked ECUs:

• All pertinent ECU power drivers and signal outputs must be read in by the test system. It must be possible to capture the signals and store them in files if required.

• The test system must be able to stimulate all the ECU inputs.

• Real electrical fault insertion capability is required on ECU outputs in order to verify how the VirtualCar system reacts to the insertion of known faults. For ECU inputs, electrical faults can often be stimulated by software.

• The test system must be able to log all CAN messages between the ECUs. To investigate the behavior of the CAN network, the test system must be able to perform the following tasks:

o Manage standard and extended identifier messages

o Trace and record on all of the CAN lines simultaneously with time stamps

o Send predefined messages interactively o Generate triggers on start of frame for

detailed analysis o Measure the time elapsed between a

certain message with identifier “x” and a message with identifier “y”

o Simulate the messages received and transmitted by nonexistent nodes and react to external triggers (events) or to events on CAN lines

o Suppress all CAN messages sent by one or more ECU

o Modify specific signals inside CAN messages and if necessary calculate a new checksum

o Generate hardware errors on the CAN bus (e.g., by inserting additional capacitors or resistors between the CAN lines, generating error frames, destroying CAN messages at arbitrary bit positions)

• It must be possible to verify network management functionality: sleep mode, alive mode, wake up mode.

• A diagnostic serial line is available on many of the ECUs constituting the test system. During test execution, it is necessary to interface the ECUs through this line to request diagnostic services and get diagnostic responses from the ECUs. In this particular case, the ability to interface to the ISO9141 serial line is required. Diagnostic communication protocols must be implemented based on this layer.

• From the ECU’s point of view, the test system must behave like a real car. This requires real-time capable models of all controlled systems, especially for the engine, transmission, vehicle dynamics and some of the body/comfort components.

• For manual interactive operation of the system, the experiment software must be powerful and flexible, but also easy to handle. The ability to automate the overall test system is crucial. For such a large system particularly, it is necessary to have powerful automation software with a well structured automation concept.

ELASIS was looking for an HIL simulator which was able to fulfill as many as possible of these and other requirements. After evaluating the HIL simulators available on the market, ELASIS opted for the dSPACE Simulator over other HIL vendors’ products. One reason for this decision was good experience with using dSPACE Simulator Mid-Size for single ECUs (engine controllers) and for a small ECU network (engine and transmission controllers). In addition, ELASIS had had positive experience of the entire dSPACE tool chain for ECU development. The experiences of other parts of the FGP group also contributed to the decision.

VIRTUALCAR TEST SYSTEM FOR NETWORKED ECUS

HARDWARE SYSTEM SETUP

The main objective of the first phase directly after project start was to define the detailed system specification of VirtualCar. A team of experts from ELASIS and dSPACE worked closely together on this for several weeks. The results were summarized in the system specification document. This also included minor changes to the requirements contained in the original requirements specification document. This chapter provides the hardware and software details of the VirtualCar system. The VirtualCar is based on dSPACE Simulator Full-Size. The main reasons for choosing the Full-Size technology were:

• High level of reusability and modifiability for all hardware, particularly with respect to later adaptation to new projects

• The large number of input and output signals required

• The need to contact a large number of ECUs

Figure 3: Overview of VirtualCar hardware components

Figure 3 gives an overview of all hardware components used in VirtualCar. The heart of VirtualCar is formed by three 19” cabinets. One cabinet is dedicated to the B-CAN ECUs. The C-CAN network is divided into two cabinets. One is for the vehicle dynamics ECU, ACC and steering angle sensor. Since this sensor is a regular node on the C-CAN network of the Stilo, it is also integrated in the VirtualCar as a real part. During the concept phase it was decided not to integrate the electric power steering node as a real part but to simulate it by generating its CAN messages with the VirtualCar. The decision took into

account the work involved in integrating a real power steering node and the benefit to be expected of it. The engine controller and the ECU for controlling transmission are connected to the third cabinet. Each of the Full-Size cabinets is constructed similarly and contains:

• The high-speed real-time processor for calculating the dynamic models, standard I/O and CAN traffic

• I/O cards for acquisition and generation of discrete signals, boards for receiving and transmitting CAN messages. A special HIL board (the DS2210 HIL I/O Board) was used for the engine control unit. This contains special functions for generating and reading crank-angle-based signals with high accuracy and convenience.

• The multiple modular dSPACE signal conditioning components

• FIU and load boards to make real or simulated loads available on ECU outputs and generate electrical faults.

• Integrated break-out boxes for accessing discrete signals. Since the number of signals for B-CAN ECUs is very large, and the signals can be accessed via terminal strips on the ECU cabinet, there are no break-out boxes in the HIL cabinet for the B-CAN ECUs.

In addition to these universal contents, there are further components integrated in the HIL cabinets:

• One common power supply (battery simulation) for the whole VirtualCar

• An adaptation system for the ESP controller. Since this ECU drives the hydraulic valves via integrated coils, the adaptation system is necessary for sensing the magnetic field of the coils by Hall sensors.

• A/W bus gateway: This component, developed by NSI, France, serves as a gateway between CAN and the Fiat A- and W-busses. Using this component makes it possible to generate messages on Fiat busses by sending specific CAN messages on a private CAN. The box translates these CAN messages into corresponding A-bus or W-line signals.

• CANstress system: CANstress, a combination of hardware and software from Vector Informatik, can introduce several types of CAN faults which cannot be generated by the dSPACE CAN boards. Its functions include generating fault frames and the inserting capacitors between CAN high and CAN low. A separate CANstress box is used for each CAN network (B-CAN and C-CAN).

All the ECUs for the B-CAN network and the ECUs for transmission and engine are located in separate ECU cabinets.

The host PC is used both to develop models and to configure and run the experiment and the test automation software. The PC contains a CANcardX for accessing the CAN busses (B-CAN or C-CAN) for particular purposes like providing bus statistics. Additionally, the PC contains an EDICcard2 from Softing for accessing the K-Line for diagnostic services.

Figure 4: VirtualCar in the laboratory

The following list of input and output channels used in the VirtualCar (Figure 4) clearly demonstrates the complexity of the system:

• 88 ADC channels • 99 DAC channels • 366 channels for digital I/O • 6 resistor simulation channels • 10 PWM input channels • 10 PWM output channels • Further special channels for ignition, injection,

crank, and cam • Four different CAN controllers, two for each

CAN network, for providing a gateway and fault simulation in the Simulator

The total number of ECU pins connected to the test system is about 900.

SPECIAL HARDWARE SOLUTIONS

Fault Simulation Concept on CAN

Figure 5: CAN fault gateway

Figure 5 shows how the requirements for testing fault behavior on the CAN network are met. The solution shown in Figure 5 is implemented both for the B-CAN network and for the C-CAN network. Two CAN controllers for each network are implemented in the Simulator. Each ECU can be connected separately to either of them. All messages received on one controller are immediately passed to the other controller via the Simulink® model. This ensures that each ECU receives the CAN messages of the other ECUs even if they are connected to different CAN controllers. The delays that occur are so slight that the ECUs are not affected by them. Since transmission is fully under software control, it is easy to generate fault cases down to message or individual signal level. Stimulation of Steering Wheel Sensor

The steering wheel sensor (LWS3 , Bosch) is a regular node on the C-CAN network. It was therefore a requirement to include it in the VirtualCar as a real component. The LWS3 steering angle sensor contains two AMR (anisotropic magneto resistance) elements. Above each element, there is one gear wheel with a permanent magnet, whose rotation depends on the steering angle. The gears rotate at different speeds, resulting from their different numbers of teeth. Each AMR element consists of two independent Wheatstone bridges, which are used to generate an output voltage according to the angle of the associated gear wheel. Since the rotation of the steering column is simulated by the vehicle dynamics model, it is necessary to stimulate the sensor in such a way that the microcontroller recognizes a correct rotation angle.

For this task, the gear wheels were removed and the inputs of the AD converters directly stimulated by analog outputs of the Simulator, in the form of sine and cosine signals with a specified phase relationship.

Figure 6: LWS3, Bosch steering angle sensor.

High-Speed Data Acquisition

Another requirement of ELASIS was to have eight additional, analog inputs with much higher sampling frequencies than the standard I/O channels related to the real-time model. The inputs can be connected flexibly to any of the electrical signals to make a precise analysis. High-speed ADC measurement is realized by reading the ADC channels in a separate task, which is calculated with a sampling period of 50µs (20kHz). This task is triggered by a separate timer interrupt on the corresponding processor board and has the highest priority. The task also includes a separate capture service to trace the data with a sampling period of 20 kHz. The sophistication of dSPACE software (Real-Time Interface, experiment software) makes it possible to implement this special feature easily within the Simulink block diagram and to access the high-speed signals together with all the other signals in the same ControlDesk experiment. SOFTWARE COMPONENTS

Real-Time Software

Most parts of the controlled system and the I/O of the VirtualCar are specified in MATLAB®/Simulink®.

The multiprocessor blockset RTI-MP makes it possible to specify all models for the complete system within one Simulink model. Figure 7 shows the top level of this model.

Figure 7: Simulink model, top level

It mainly consists of four subsystems, one for each processor:

• Body electronics (BODY) • Vehicle dynamics (VEHICLE) • Engine and transmission (ENGINE) • High-speed analog measurement

(MEASUREMENT) The subsystems for body, vehicle and engine are each divided into one part for the complete I/O model and another part for the corresponding dynamic models. The body’s I/O part benefits from a certain model structure inside the I/O model. The structure developed by dSPACE contains a very clear and logical hierarchy. This makes it easy to find I/O signals from among hundreds of other signals. To simulate the dynamic behavior of the diesel/gasoline engines and the three-dimensional movement of the car, use is made of the well-tried Simulink models en-DYNA and ve-DYNA. (TESIS GmbH, Germany). Ve-DYNA was enlarged by a module for the simulation of ACC traffic. The model for automated manual transmission (Selespeed) was developed by ELASIS. Body Models Unlike applications for the powertrain or vehicle dynamics, car interior comfort frequently requires only a very simple model of the controlled system. Complex, nonlinear, high-order differential equations are replaced by small kinematic function models. For example, to control the windshield wipers, the ECU expects the moving wiper to pass through the park position regularly, depending on the wiper speed. The feedback comes from the “wiper park position” signal, which has to be activated cyclically.

Here are further examples of such comfort models:

• Movement of the seats: The driver/passenger seat nodes control the positions of the backrest, height and slide motors by means of the input signals provided by their Hall sensors. As these electrical motors are replaced by high-impedance simulated loads, a kinematic model which simulates the movement and generates Hall sensor signals according to the movement is needed.

• NCL (climatic controller): The NCL controls the positions of four motors by means of the input signals provided by their position potentiometers. As these electrical motors are also replaced by simulated loads, a kinematic model for simulating the movement of the four motors is necessary. The potentiometer signals are generated according to the simulated positions.

• Additionally, the NCL regulates the position of the air recirculation flap by observing the current flowing through the controller output pins. The end positions are detected by a high current after a specific period of low current. To simulate this behavior, an easy time-based model was implemented.

• The side view mirror movement is controlled by the door ECU, by observing the position potentiometers. The real electrical motors are replaced by kinematic models.

• The real mechanism for locking/unlocking and opening/closing is reproduced by a more complex functional model.

Experiment Software

The entire graphical user interface for manual operation is implemented with dSPACE ControlDesk. Many well-structured layouts, partly with photorealistic visualizations, enable the user to handle the system and manage the real-time experiments (see Figure 8).

Figure 8: Main ControlDesk layout

Especially for testing vehicle dynamic functions or ACC functionality, it was decided to integrate a 3-D online animation tool. The tool, from the dSPACE tool chain, is MotionDesk. It enables the movement of the car to be visualized in a virtual world. THE FULL BENEFIT WITH TEST AUTOMATION

Although it is possible to perform many tests manually, the full benefit is reaped only when automation is introduced. Since an automated test requires less time than the same test executed manually, more tests can be performed in a given period of time. This leads to broader test coverage and a greater test depth, meaning that more tests can be done and more details can be tested. At ELASIS, two different approaches are used to run automated tests with the VirtualCar. To test diagnostic functions, ELASIS uses TestPlatform, an object-oriented test system developed by ELASIS over the last two years for testing engine control units on dSPACE Simulator Mid-Size. The well-structured object-oriented design enables the software to be adapted to the VirtualCar, so many existing tests can be reused. For functional tests of the body and comfort electronics, a new test project based on the new dSPACE software AutomationDesk is under development. Both approaches are described below. ELASIS TESTPLATFORM

The first objective was to define a generic test procedure for the self-diagnosis software of the ECU with respect to project-specific requirements and international standards. The test procedure was derived from the test specification and from the knowledge of the experts who perform these tests every day on the car. Originally, the test procedure was then implemented on dSPACE Simulator Mid-Size by developing a software environment in Python code for test creation and management. An object-oriented approach allows a dynamic and hierarchical test structure and automatic test report generation. The main advantages of this approach are the maintainability, reusability and repeatability of tests. Self Diagnosis Software

The ECUs are programmed with self-diagnosis software (on-board diagnosis), which allows management of the faults arising in the plant to be controlled (i.e. engine, transmission, etc.). In addition, the ECU passes the descriptive and standardized diagnosis trouble code (DTC) of the detected faults to diagnostic communication software via K-line or via CAN bus.

Fault detection and the DTC management are specified by the European On Board Diagnosis (EOBD) standards in Europe and the California Air Resources Board (CARB, OBD II) in the US. These rules have been included and extended in the self-diagnosis specification (SDS). These are some of the functions covered by a generic engine SDS:

• ReadDataByLocalIdentifier (RLI) Check ECU variables accessibility and conversion

• Inputoutputlocalidentifier (IOLI) Check ECU actuators

• StartRoutineByLocalId Launch procedures (i.e., self-learning)

• Other KeyWord2000 Services • Scantool Services • DTC

with the basic OBD structure: o Drive into specified operating point o Activate electrical\logical\model fault o Read out ECU diagnostic memory o Evaluate test by comparing the detected

fault with the expected fault o Generate report automatically

has been improved to include the EOBD test concepts (see flowchart in the next section).

u s in g S E R V IC E 1 8

C h ec k D T C

U s in g S E R V IC E 1 7 R ea d th e S ta tu s o f D T C

(s to re d pa ram e te r by E C U d ur ing fau lt in se r tion )

E R R O R F a u lt N o t fo u n d E X IT c as e: 1 - C o m u n ic a t io n O F F c as e: 2 - D T C N o t fo u n d c as e . 3 - n u m _o f_ D T C != ca lib ra ted _n u m _ o f_D T C

U s in g S E R V IC E 1 2 R ea d K w 200 0 F ree ze F ram e

(R e qu es t re ad F ree zeF ra m eD ata )

C he ck M od e l P a ram e te r V S S ta tus o f D T C

W A R N IN G : pa ra m e te r n o t c o r rec t, va lue ou t o f r an ge

e rro r

C he ck M od e l P a ram ete r V S

K w 2 00 0 F re ez e F ram e

W A R N IN G : pa ra m e te r n o t

e rro

C ha ng e com u n ic a tion p ro to co l

R e ad S ca n T o o l F re ez e f ra m e

& & m od e 3 s ta tu s m od e 7 s ta tu s

C he ck M od e l P a ram ete r V S

S c an T o o l F re ez e F ram e

W A R N IN G : pa ra m e te r n o t co rrec t, v a lu e ou t o f ra ng e

e rro r

C he ck m od e 3 / 7 d ue to M il ca lib ra tion & d r ive

cyc le

W A R N IN G : E rro r on m od e 3 / m o de 7

e r ro r

C he ck R e co ve ry du e to p ha se

W A R N IN G : R e co ve ry no t co rrec t

K e y_ O ffP ow er_L a tc hK ey_ O n

er ro r

e rro r

C h e c k M IL d u e to :

- M IL c a lib ra t io n - d r ive c yc le

E R R O R : M IL no t c o r rec t

- - - d r iv e c yc le = m a x_ nu m _ o f_ d r ive _c yc le_ to_ do

e rro r

ou t o f de va lid a tion tim e

W A R N IN G : pa ram e te r no t co rre c t, v a lu e o u t o f ra ng e

C H E C K

ch eck e ve n t cou n te rE R R O R

E v en t c ou n te r : d id n 't de c rea se

p h a s e d e l

p h a s e o n / o ff

Figure 9: Flowchart for CHECK Item

Test Requirements

The previous items concerning the DTC have been formalized in a flowchart that describes the steps to be performed. The steps have to be performed for each DTC (i.e., P0201), for each fault symptom (e.g., short to GND, short to battery) and for each test condition (detection rules), e.g., power-on, cranking, engine run and vehicle run. When a DTC, a fault symptom and a detection rule have been defined, a generic test could be performed as follows:

• Fault insertion with the correct fault symptom • Check • Fault off • Check • Fault insertion with different fault symptom • Check • Fault off • Check

Figure 9 shows in detail how “check”: is structured. The CHECK block has these items:

• Check DTC using Service 18 • Check model parameter VS status of DTC using

Service 17 • Check model parameter VS KW2000 freeze

frame using Service 12 • Check model parameter VS ScanTool freeze

frame • Check ScanTool mode 3/7 due to MI calibration

& drive cycle • Check recovery status • Check MI status due to MI calibration & drive

cycle These steps are performed several times during test execution, depending on the test phases:

• Fault ON • Fault OFF • Change symptom ON • Change symptom OFF

• Fault DEL (warm-up cycles to check the decrement of the event counter)

and on the MI Calibration:

Figure 10 shows in detail how the overall generic test is structured. The Test Automation Architecture

To implement the presented test structure, object-oriented test software was designed and implemented. This has the following important advantages over a purely procedural solution:

• The test code for several OBD software versions of several ECUs (engine, transmission,...) from several suppliers can be managed, maintained and reused efficiently.

• The same test structure can be reused for functional tests on networked ECU.

The software named TestPlatform is based on the obect-oriented script language Python. To close the diagnosis loop, another third-party tool is used: Diagnosis Tool Set (DTS) from Softing. Use is made of the following dSPACE test automation libraries:

• DSTLib for accessing DTS • IOCI-LIB for accessing the electrical failure

insertion unit of dSPACE Simulator • RTPLib for accessing the real-time model

variables • WordLib, ExcelLib for automatic report

generation TestPlatform has two main substructures:

• The ECU tree: A hierarchy of all the ECUs that can be tested.

• The CAR tree: A hierarchy of all the cars that use an ECU

combination from the ECU tree.

STARTRead ECU iden tification param eter

S tart detection rules manouvre

Start waiting for Fault V alidation Time

number of Drive Cycle = number of Drive Cycle + 1

Initialize am bient parameterReset DTC

Freeze Model Parameter

drive cycle < max n um of drive cycle to do?

end of Drive Cyc le

S tart deval manouvre (Po Ck Er Vr - deval Manouvre) Fault OFF

S tart evaluation of Fault Devalidation and Time measuring

number of Drive Cycle = number of Drive Cycle + 1

drive cyc le < max num of drive cyc le to do

OR MIL Calibration == OFF

drive cycle == 1? OK

Start waiting for Fault Devalidationdrive cycle > 1

number of Drive Cycle = 0

number of Drive Cycle = 0

num ber of Drive Cyc le = 0

W arm U P Cycle

Event coun ter == 0?

num _of_RULES

ChecK ERROR DTC / MIL

W ARNING

ChecK

W AR NING

ChecK

W ARNING

S tart manouvre (P Ck E V )

Fault ON Start waiting for Fault Validation number of Drive Cycle = number of Drive Cycle + 1

Start manouvre (Po Ck E r V r) Fault OFF Start waiting for Fault

Devalidationnumber of Drive Cycle = number of Drive Cycle + 1

ChecK

W ARNING

ChecK

W ARNING

fault on

fault off

change fault simpton on

change fault simpton off

fault del

Fault Injectiondrive cycle == 1? OK

drive cycle > 1

ERROR DTC / MIL

ERROR DTC / MIL

ERROR DTC / MIL

ERROR DTC / MIL

nu mber of Drive Cyc le = 0

Figure 10: Structure of overall test

The main idea is that in the ECU tree, each ECU has its own tests and parameters but also inherits all the properties from the parent ECU. The same mechanism works for the CAR tree. All the maneuvers and distributed tests for the networked ECU can be defined at root level. For example, the maneuver VehicleChange_Gear() is defined for a manual gear box at CAR root level, but can be overwritten for a car with an automatic gear, without changing the test implementation. In the same way, the

functional and distributed tests of networked ECUs in one car are used by all the cars derived from it. TestPlatform starts by defining a root class named ECU, in which all the items of the SDS are present.

Figure 11: UML general class diagram for HIL TestPlatform

The UML diagram shown in Figure 11 is intended for general use and shows how the platform has been planned and how it can be extended. A new car, including the desired ECU, is constructed dynamically. Once the necessary ECU modules are available, a new car consisting of a subset of the ECUs can be defined. For example, the 5NF Selespeed car consists of a Magneti Marelli (MM) 5NF engine management control unit and an MM CFC228 Selespeed transmisson control unit. Some tests need very particular maneuvers for each detection rule. For example, some tests run only if they detect a specified engine speed. It was therefore necessary to create a structure that allows maneuvers (customized for each test) to be defined in the hierarchy. This was done by defining some subclasses. These use the inherited basic maneuvers defined at the car level. DTC Parameterization

The lower levels of the hierarchy have all the functionality of the upper levels, so the parameters of a test can be changed at any level, but if a major change in test structure is needed, the same test can be overwritten.

Test SDS: Report Generation

Each test produces two files, a text file to trace the diagnosis communication flow and the simulation status MATLAB file in which the model variables are stored. In addition to these files, each test session produces a final Microsoft Word report. The completion of the tests is reported to a predefined list of addresses by e-mail. Graphical User Interface (GUI)

Figure 12 shows the main layout of the TestPlatform environment. It is built automatically in ControlDesk according to the test. It provides information on:

• The running test (in the calibration frame) • The previous test result (in the LED state on the DTC

frame control) • The current maneuver (in the customized

instrumentation in the top part of the window) The DTC frame control gives all the information about the test. It makes it possible to:

• Check the detection rule • Enable/disable the fast modality (to do only 2 warm-

up cycles in the Del phase) • Read the LED states to know the result of the test

during the session and • Read the validation / devalidation time.

The DTC calibration display gives all the calibration information about the currently running test. It is refreshed for each test.

All the access functions to write the calibration parameters to this frame are provided by the GUI class.

DTC Calibration display

DTC Frame Control

Figure 12: TestPlatform main layout

With the customized instrumentation, it is possible to read the state of the model, e.g., engine speed, water temperature, and manifold pressure.

TESTAUTOMATION CONCEPT BASED ON DSPACE AUTOMATIONDESK

A second approach to test automation is currently under development(Figure 13). This will be used mainly for functional tests. It is a graphical approach based on AutomationDesk, which is the new dSPACE test automation tool. It has the following advantages over the pure Python approaches:

The integrated test project management enables the user to store and manage tests, test data, test results and test reports in one place. This facilitates close integration into the development process.

The library concept consists of global built-in libraries for basic functionality, global custom libraries for extensions to the automation functionality, and project-specific

libraries. Test components and tests can therefore be reused easily and conveniently.

Result management and report generation guarantee test reproducibility, data security, and consistency.

The deployment of AutomationDesk in the VirtualCar project is planned for 2004.

PROCESS INTEGRATION

Today the development cycle for a new car is typically 36 months. Throughout the development process, there are certain phases in which the combination of ECUs is tested with the HIL system. To ensure that the system adapted to the ECUs is available in time for these phases, close cooperation between the HIL system supplier and the OEM is necessary. The HIL system must be constantly available during the test phases. It must run 24 hours per day, up to 7 days per week.

Figure 13 AutomationDesk: Libraries and graphical test sequence

ELASIS decided to gain experience with VirtualCar before using it in a tight project schedule. So at the beginning, the system was configured for the Stilo ECUs at a late phase in the development phase. Now the system is in full operation, it will be updated for a complete new car . In this new project, VirtualCar will be used from the very beginning. At the same time as the ECU suppliers develop the first version of their ECUs based on the ECU specifications, the virtual car will be updated according to the same specifications. It is essential to ensure that the HIL system update will be finished and new automatic tests implemented by the time the first versions of the ECUs are available. The new ECUs can then be tested intensively for a period of four months. APPLICATION EXAMPLES ON VIRTUALCAR

One example of automated testing on the virtual car is testing indicator light activation. In the Stilo, this function is distributed across the body computer (NBC), the dashboard ECU (NQS) and the adaptive cruise control ECU (NAC). The NBC receives the request for indicator light activation from the indicator switch and calls the relevant command. It sends the message TurnLightFaultSts on low-speed CAN and the message TurnSignalSts both on low-speed and on high-speed CAN.

The messages on low-speed CAN are used by the NQS to show the driver that the indicator light has been activated, both in the nominal case and in the fault case. The message on high-speed CAN is used by the NAC if the Adaptive Cruise Control was inserted. The TestPlatform structure was used for testing cases in which the driver activates the indicator light in nominal conditions (fault off phase) and in fault conditions (fault on phase). The fault selected is DTC 9007, taken from the specification of the NBC, which describes the detection of an electrical fault in the indicator light. The test consists of:

• Inserting an electric fault (connection to Vbat) for the indicator light by means of the FIU

• Investigating by means of the DTS whether the NBC detected the fault correctly and wrote it to the fault memory correctly

• Reading through the correct message flow on the CAN lines

• Establishing consistency between the indicator light indication on the dashboard and in the CAN messages.

CONCLUSION

The ever-increasing complexity of electronic systems in modern vehicles requires new ways of developing and testing ECUs and their functionality. After a discussion of the questions arising when networked ECUs are to be tested, the requirements for a corresponding test system were derived. VirtualCar, a complex and powerful tool for testing the entire ECU network of a Fiat Stilo based on dSPACE hardware-in-the-loop simulators, was presented as a solution. Two complementary approaches to automated tests were presented. These approaches provide a reduction in test execution time, reliability of tests due to the repeatability of external and internal conditions, and the ability to perform more exhaustive tests by easily modifying the test conditions. Moreover, the risk of human error due to stressful, repetitive work is reduced.

REFERENCES

1. Schütte, H.; Plöger, M.; Diekstall, K.: Wältermann, P.; Michalsky, Th.: Testsysteme im Steuergeräte-Entwicklungsprozess. Automotive Electronics, pp. 16-21, March 2001

2. Gehring, J.; Schütte, H.: Automated Test of ECUs in a Hardware-in-the-Loop Test Bench for the validation of Complex ECU Networks. Proc. of the SAE World Congress, Detroit, USA, March 2002

3. Lamberg, K.; Richert, J.; Rasche, R.: A new Environment for Integrated Development and Management of ECU Tests. Proc. of the SAE World Congress, Detroit, USA, March 2003

4. Köhl, S.; Lemp, D. ;Plöger, M. : Steuergeräte-verbundtests mittels Hardware-in-the-Loop Simulation. pp.948-955,ATZ , Wiesbaden, Germany, October 2003

5. Di Mare, G.; Ferrara, F.; Scala, S.; Sepe, E.: Hardware In the Loop testing of EOBD strategies. Proc. of the 15th IFAC World Congress, Barcelona, Spain, July 2002

6. Caraceni, A.; De Cristofaro, F.; Di Lieto N., Ferrara, F.: Gasoline Rapid Control Prototyping System for Fiat Punto 1242cc 16v. Proc. of the AVEC ‘02 Congress, Hiroshima, Japan, September 2002

7. Caraceni, A.; De Cristofaro F.; Ferrara, F.; Philipp, O.; Scala, S.: Benefits of using a real-time engine model during engine ECU development. Proc. of the SAE World Congress, Detroit, USA, March 2003

8. Gruber, J; Steering Wheel Angle Sensor for Vehicle Dynamics Control Systems. Proc. f the SAE World Congress, Detroit, USA, February 1997