A.

1
Model-Based Testing of Automotive Electronic Control Units
Ghmann, Clemens {clemens.guehmann@tu-berlin.de} Technische Universitt Berlin, Department of Electronic Measurement and Diagnostic Technology Einsteinufer 17, Sekr. EN 13, D-10587 Berlin, +49 (30) 314 29393

Introduction

Owing to increasingly strict legislation, as well as customers high expectations involving driving comfort, performance, and safety, the complexity of the power train of modern motor vehicles has tremendously increased. Absolutely essential achievements necessary to ensure conformity with current and future environmental legislation will include advanced engines with a multitude of controllable components, as well as the application of advanced transmission systems. It will furthermore be possible to satisfy requirements placed on future vehicles only by networking electronic control units (ECUs), and by implementation of the functions distributed throughout these units. Application of innovative methods in the development of ECUs, input of their data, and their testing is essential to successfully contend with the resulting complexity of ECU software, and with the associated development cycles that have consequently become increasingly shorter. Mounting cost squeezes additionally rule out any luxury of cost rises in such work. In contrast to development and testing in road trials exclusively practiced in earlier years, simulation in software development and in calibration has now attained an increasingly dominant role. It is possible to satisfy quantitatively and qualitatively increasingly stringent specifications in ECU testing only through an optimized and planned test process in all development phases. One solution for optimization of the test process with respect to testing depth and incurred costs is application of automated testing in hardware-in-the-loop, software-in-the-loop, and model-in-the-loop simulation. Application feasibility of these simulation methods, however, is assured only if the models employed feature the required degree of detailing, and most essentially if these models are available on time: i.e., by beginning of the corresponding development-process phases (for example, the software-testing phase). Without a restriction in general applicability, this presentation will focus on the particular aspect of testing ECUs in the power train. The section below will begin by describing the application of simulation in the development process of automotive ECUs. Section 3 will present a comparison of the HiL, MiL, and SiL simulation techniques, and will discuss the advantages and disadvantages of each. Section four will elaborate in detail on model generation as required for such simulation. The application of simulation for automated ECU testing, in Section 5, will highlight the relationship of these techniques to actual practice.

Simulation in development of automotive ECUs

The so-called V (see fig. 1) model offers a good illustration of the application of simulation. The type of simulation applied will depend on the particular step of development. The point of departure for ECU development is the customers specifications, made available at the beginning of software development in the form of a catalog of user requirements. The step following system specification is function specification, which can be supported by model-in-the loop simulation (MiL 1). Model-in-the loop simulation takes place on a PC or workstation, with simulation of both the specified functions as well as the vehicle itself. This step features development of the functions as software models in graphically oriented programmer systems such as MATLAB /Simulink . Design and determination of the functions then follow in detail. The result is an electronic catalog of specifications that can be implemented. The following step entails direct testing and optimization of the software models of the functions, with the appropriate software and hardware tools: on a bypass computer in the vehicle, or on a test bench (i.e., by rapid prototyping 2). Model-in-the-loop simulation and rapid prototyping enable finding and elimination of specification errors in an early phase. Software design and coding for the target system i.e., implementation of the functions in software capable of series production are incorporated in the process steps of program design, module design,

customer Kunde

Anforderung requirements

4 5 6 calibration Applikation

system Systemspezifikation specification

Funktionsspezifikation 1 specification Programmentwurf program design Modulentwurf module design

4
rapid prototyping Rapid-Prototyping

system test Systemtest

and coding. These process steps are ideally accompanied by intensive static analyses, in the form of reviews. To an increasing degree, advanced autocode generators are supporting the coding phase. The subsequent module test, required for verification of the module design, can be supported by software-in-the-loop simulation (SiL3). The software model used earlier in model-in-the-loop simulation is replaced here by the later series code, and is integrated into the simulation. The integration test performed next is intended to test the executable program in interaction with the other modules, the operating system, and the hardware components used. During this phase, a hardware-in-the-loop simulator (HiL 4) supports the engineer. The subsequent function and system tests are likewise unfeasible at the required testing depth without the use of a hardware-in-theloop simulator.

functional

4 functional test Funktionstest 4 integration test Integrationstest 3

Modultest module test

Softwarentwicklungsprozess development process

coding Codierung
2 Rapid-Control Prototyping 2
Regelstrecke control plant im Fahrzeug in the vehicle

1 Model-in-the-Loop Simulation 1
vehicleSimulink Fahrzeugmodell model
Simulink- Modell model of der Software the software

model of Simulink Modell der Software the software

Bypass Steuergert ECU

3 Software-in-the-Loop Simulation 3
vehicleSimulink Fahrzeugmodell model
Software software Seriencode series code

4 Hardware-in-the-Loop Simulation 4
vehicleSimulink Fahrzeugmodell model
Simulator

ECU Steuergert
Steuergert ECU

5 Offline Simulation (DoE) 5

engine Simulink model Fahrzeugmodell
Kennfeldoptimisation o ptimierung

66 Hil Simulation onPrfstand Simulation am a test bench

vehicle Simulink Fahrzeugmodell model
Simulator

test bench Prfstand

control parameter Schaltkennfedl Kennfelder, z.B.

The next step calibration of the ECUs (i.e., determination of the parameters and characteristic curves) nowadays increasingly takes place on HiL simulators, by means of offline simulation (5). HiL simulation, furthermore, has assumed an increasingly essential role in rig testing and acceptance testing (6). At this point, for example, it is possible to simulate the rest of the vehicle on engine test benches with transmission, driver, and driving resistance in order to be able to drive e.g. a New Europead Driving Cycles (NEDC).

Fig. 1: Simulation in the development process

HiL, MiL, and SiL simulation for ECU testing

HiL simulation can be successfully employed for testing both individual as well as networked ECUs. For such purposes, the real ECUs must be available at least as prototypes. Fast computer hardware (i.e., the simulation system) virtually simulates, in real time, the relevant components of the vehicle, the driver, and the environment. The HiL system furthermore offers powerful I/O ports: in order, for example, to read in the set values (manipulated variables) of the real ECU via A/D converters for the simulated actuators. The real ECU generates these set values. In addition, the HiL system must also offer the required outputs e.g., for pulsewidth-modulated signals or for D/A converters in order to enable represen-tation of sensor values for the ECU. Fig. 2 MiL SiL (PC) SiL (Processor) HiL depicts the mode-ling depth for HiL, MiL, and SiL simulation. Vehicle + Driver + Surroundings HiL simulation generally involves integration into the simulation loop of a number of real parts (actuators and sensors) e.g. a throttle-valve actuator. Work in function and software development for the power train is now increasingly moving toward generation of specifications in a graphicsoriented modeling language such as Simulink . As a result, an executable model of the software is provided in a very

Sensors

Actuators

HW-Interface

HW-Interface

Hardware

Operating System / Hardware Abstraction Layer

Functional Software

Software

ECU
Can-Network

Fig. 2: Modeling depth for MiL, HiL, and SiL simulation

early phase of the development process. Once this software model is complemented by models of the actuator and the sensor systems, it is then possible to simulate the entire system in MiL. If, in a later step of the development process, this software model is replaced by the converted code (series code), the result is known as software-in-the loop simulation. Simulation then runs entirely on a PC, and it is possible to test the ECU code, also for individual modules, entirely apart from an ECU itself.
Simulation-model repository PC for test engineer Simulation computer

Fig. 3 depicts an additional variation of SiL simulation [1]. In contrast to PCbased simulation, this variation involves loading the code onto the target processor. It is possible to set up a PC to include all tools for the build of Serial monitor Test documentation project-dedicated simulation environDeveloper board ments, and for conduct and analysis of Fig. 3: Test configuration for SiL Simulation (processor) the tests. The serial monitor allows access to the embedded system, which is controlled via this monitor. Status information can be displayed, and the software to be tested can be loaded. It is not necessary for the development board to include all the interfaces of the ECU. The serial monitor, however, is absolutely necessary as is an interface for linking to simulation. It is possible, for example, to implement such interfaces via Ethernet or a field bus. The simulation-model repository shown here is a database system that enables provision of simulation modules for multi-project applications. Operation of the simulation process is closely linked to the development board: i.e., simulation is temporally synchronized with the embedded system. Selection, start, and termination of the simulation process takes place from the serial monitor. The test server is used to administer the test documents that are automatically created during testing. A Server provides the testing engineer access to the test documentation for evaluation of the test runs. In addition, the scripts required for automation of the tests are filed on this server.

Model generation for MiL, SiL, and HiL simulation

The ideal solution generally attempted is to use the same models for MiL, SiL, and HiL simulation. This solution, however, requires real-time-capable simulation models. Owing to the requirement that HiL simulators should be faster than the ECUs to be tested by a factor of approx. 10, simulation increments of approx. 500 s will result, for operations with advanced power-train ECUs that have clock-pulse periods less than 10 ms. The models to be implemented must therefore be so simple as possible in their mathematical description but yet must simulate the dynamic behavior of the vehicle, with sufficient account taken of all controlled variables. A complete model for the transmission ECU test, for example, will contain especially for automatic conduct of testing, and in addition to pure simulation of longitudinal dynamics the following components: a driver model, the possibility of taking various driving courses and environmental conditions into account, as well as possibilities to simulate errors (e.g., transmission faults). This model must be expanded to include lateral dynamics for testing of the ECU network. In addition to the Simulink system, oriented as it is to signal flow, the object-oriented language Modelica has proved effective in this context.

T Engine Clutch

T M Transmission

T M

Vehicle Dynamics

Fig. 4: Modular structure of the model for a power train The model presented here was created from the Simulink library VeLoDyn, as part of a project executed in collaboration with the Berlin company IAV GmbH. With its sub-models for the engine, clutch, transmission, and the vehicle dynamics, this vehicle model simulates the longitudinal dynamic behavior of the entire power train. Utilization is made here of a torque-speed interface (see fig. 4), whereby the moment balance is distributed to the individual moduls. The moment originating from the engine is

successively reduced along the power train: i.e., by the load moments of the individual components. Feedback takes place by means of rotational frequency, transferred from the wheel in the direction of the engine. This torque-speed interface makes a modular build of the power train possible. 4.1 Virtual driver [2] In order to achieve the greatest possible degree of automation for testing, a virtual driver is required that can for the purpose of driving through prescribed test cycles activate the actuators for pedal sensor and brake pedal, thereby observing specifications for a particular speed value. Independently of the speed regulator, simulated (software) ECUs are employed to activate the clutch and the transmission system. The specified gear in which the transmission is to be operated is provided to the transmission ECU, as a factor of the stipulated speed. The primary criteria of the virtual driver are asymptotic behavior in stationary state (i.e., constant speed), as well as observance of a tolerance range around a required speed. The virtual driver consists of the modules for the pedal-sensor controller and the brake controller, which are switched in parallel. The outputs are activated via a priority controller in alternative and mutually exclusive modes. 4.2 Internal-combustion engines In most cases for HiL, MiL, and SiL simulation, combinations of model structures are used. Integration of the phenomenological description models complements the basic physical structure. See fig. 5 for an overview of the various types of modeling, especially for simulation of internal-combustion engines. For simulation of an internalcombustion engine, rough distinction can be drawn between the physically based approaches, and the Black Box White Box phenomenological description Models Models by mathematical models of the input-output behavior on the basis of observed Non 0-dim. 1-dim. 3-dim. parametric parametric Models Models Models measurements. In physical DoE modeling, distinction still takes Freqeuncy Response Neural Networks place among the dimensions under consideration: three-, Combined one-, and zero-dimensional. Models In the past, it has proved extremely resourceFig. 5: Combined model structures for internal-combustion engines consuming to obtain and parameterize such models purely on the basis of engineering and design data. One chief problem is that the simulation models interlinked in such configurations have for the most part not been real-time capable. Another difficulty is that it is often impossible to acquire the engineering and design data in the time required.
Data based Models Theoretical Models

For HiL simulation, one- and three-dimensional models are not suitable owing to the extremely great amount of computer capacity and time required. With zero-dimensional models [3], the engine is broken down into component assemblies (e.g., cylinders, exhaust-gas turbines, etc.), with subsequent determination of the respectively predominant states. This approach represents a compromise between commitment of computer resources and computed exactness. In most cases, zero-dimension models are combined with the phenomenological models. Whereas a zero-dimensional model is used for description of the fuel and air paths (see fig. 6), production of moment (i.e., the combustion process) is represented by a phenomenological sub-model. For such modeling, various mathematical approach such as grid maps, neuronal networks, and polynomials [4].

DK

E.V.

& mL ,DK
ps, Vs
Saugrohr

& mS

intake manifold

fuel path
& mL,Zyl

air-fuel mixture

& & (m mL,Zyl ) dt RL TS pS = L,DK VS

Air mass flow in durch das Saugrohr Luftmassenstrom the intake manifold : 2 & & & & m S = (mL,DK mL,Zyl ) = mL,DK mL,AS n Manifold pressure Saugrohrdruck:

air path torque

friction torque

theoretical model for intake manifold pressure

DoE polynom model for torque

M D = a0 + a1 n + a2 rl + a3 ZW + a11 n 2 + a22 rl 2 + a33 ZW 2 + a12 n rl + a13 n ZW + a23 rl ZW + a123 n rl ZW + a112 n 2 rl + a113 n 2 ZW + a233 rl ZW 2 + a223 rl 2 ZW + a111 n 3 + a3 ZW 3
fr 720 min 1 n 4200 min 1

Fig. 6: Combined model structures for simulation of an internal combustion engine 4.3 Clutch and transmission system The transmission and clutch models are each created as dual-mass systems, consisting of input and output shafts. With the aid of a state machine, switching is possible among the possible states, and the corresponding solutions for the differential equations are calculated. These states for the clutch are: open/slip, and closed. The transmission has a comparable structure, but with three states. During normal driving operation, when a gear is engaged, the state is normal operation. If is it necessary to switch gears, the gear is disengaged, and the idle state is activated. When the requirement exists to engage a new gear, the system switches into the synchronization state. When speed equality is achieved, the system returns to the normal stage. The effective moments of inertia are then calculated, in accordance with the gear that is engaged. 4.4 Vehicle dynamics For calculations involving vehicle dynamics, the propulsive power FP is determined from the engine moment through the transmission and the differential transmission ratio (iG and iA). The following act in opposition thereto: the acceleration force; the driving resistance, consisting of rolling (FR), wind (FW ) and climbing resistance (FC); as well as the braking force applied by the driver (FB). The following equation defines the acceleration of the vehicle:

mveh && = FP FW FC FB x 5 Test management and automated test processes [5]

(1)

ECU tests must be closely linked to software development in a defined process (see fig. 7). In order to enhance process reliability (i.e., reproducibility of the results), a test-management system is essential. A test-management system integrates the individual test-process steps into one environment, and provides comprehensive information and results. In addition to acquisition of the specified requirements and of the test cases, as well as to creation of the test plan, a management system enables initiation of the automated test and its evaluation via the appropriate interfaces. For the above reasons, all the components of a simulation system must be remote-controllable: beginning with the simulator and extending to the table calculation program that produces the test documentation. Script languages such as TcL/Tk and Python have become extensively accepted for this purpose. The

tools used for specification of the tests now increasingly support automatic generation of the scripts. For example, automation programs are created in Python from an UML sequence diagram. The error database, likewise integrated in test management, documents the results of all testing cases: e.g., as either with or without errors. The management system records test conditions as exactly as possible, in order to be able to reproduce any errors that occur. An essential point after each test cycle is determination of the degree of maturity of the software. In this process, comparison is necessary of the specified requirements with the extent to which they have been covered by successfully conducted test runs, including the remaining errors. A record of the course of errors and of test results is also an essential part of test management.

Fig 7: Test process

Summary and outlook

This presentation provides an overview and a description of the possibilities offered by simulation for the testing of automotive ECUs. Elaboration is made of the simulation methods MiL, SiL, and HiL, and of the methods for obtaining real-time-capable models for simulation of the longitudinal dynamics of a vehicle. Future developments will reveal the extent to which tests will also be performed with SiL simulation that are now running predominantly on HiL simulation systems. A test-management system is the ideal platform for simulation of the entire test process. The integration of automated tests for MiL, SiL, and HiL simulators, as well as management of the models required for model-supported tests, will in this context gain in importance in the future for work in the area of automobile electronics.

References
[1]
Maibaum, O.; Rebeschie, S.: Test von adaptiven Softwaremechanismen zur Fehlerkompensation. Simulation und Test in der Funktions- und Softwareentwicklung fr die Automobilelektronik. Haus der Technik (HdT) Tagung, 14./ 15. Mrz 2005 (accepted). Heidrich, I: Simulation und Optimierung eines Kurbelwellenstartergeneratorantriebstrangs mit Motor und Getriebekupplung. TU Berlin, Diplomarbeit am FG Elektronische Mess- und Diagnosetechnik, 2004 Offer, T.; Hntschel, U.: Virtuelle Entwicklung und Test von Steuergertefunktionen im dynamischen Fahrzeugbetrieb. In Steuerung und Regelung von Fahrzeugen und Motoren AUTOREG 2002, Mannheim, 15. u. 16. April 2002. VDI/VDE Ghmann, C.; Rpke, K.; Lindemann, M.: Gewinnung echtzeitfhiger Modelle fr die Hardware-inthe-Loop Simulation mit Hilfe der statistischen Versuchsplanung. VDI Symposium Mess- und Versuchstechnik im Fahrzeugbau. VDI-Berichte Nr. 1616, 2001 Endt, P.; Reinhold, A.; Mitzlaff, D.: Testmanagement als Integrationsplattform fr Testaufgaben und Testwerkzeuge in der Automobilelektronik. Infotainment / Telematik im Fahrzeug, S. 89-98, expert verlag 2004 Broekman, B; E. Notenboom; E.: Testing Embedded Software. Addison-Wesley, 2003.

[2]

[3]

[4]

[5]

[6]