FULL VIRTUALIZATION OF RENAULT'S ENGINE MANAGEMENT SOFTWARE APPLICATION TO SYSTEM DEVELOPMENT D. von Wissel, Y. Jordan,, RENAULT A. Dolha, J. Mauss QTronic
Introduction Renault has an established engine control SW development framework Field of application: Passenger Veh. & Light Duty Veh. with Diesel & Gasoline engines Framework is heavily based on Matlab / Simulink and the idea of MBD Renault EMS architecture SW is composed out of 20 functions (ex. Air System, Combustion, ) A function consists of modules which are the smallest testable SW unit A module contains runnuables triggered by the Operating System (OS) 2009-01-1082 2
SW development framework at Renault 1.Specification of about 200 generic configurable modules per ECU using MATLAB / Simulink. 2.Generation of C code (EMS application software) from all module specifications 4.Configuration of modules to fit to the specific needs of a software project,. Function Developers.mdl.m modul modul MiL code generation Unit testing C code modul modul SiL build for standard EMS library EMS C code library Software Project Team configuration for target CPU weeks Project C code platform integration.hex flash 5.Integration of generated configured C code on supplied target hardware, feedback for developers function 3.MiL test and feedback for software project team software integration test function HIL testing 6.Validation of all modules on system level using the real ECU 3
Assessment of SW development framework Critical assessment of the development framework There is considerable delay between delivery of a set of specs to SW project team and system-level tests based on an ECU that runs entire SW. Function Developers.mdl code generation.m 1. 2. modul modul MiL 3. Unit testing C code modul modul SiL build for standard EMS library EMS C code library Software Project Team configuration for target CPU weeks Project C code platform integration.hex flash feedback for developers function feedback for software project team HIL testing software integration test function 4
Place of vecu in SW development framework Motivation I. Virtualization System-level test and should be performed interleaved with steps 1, 2 and 3 replacing the actual MiL, SiL process by a full ECU Function Developers.mdl code generation.m 1. 2. modul modul MiL 3. Unit testing C code modul modul SiL build for standard EMS library build vecu for MiL EMS C code library Software Project Team configuration for target CPU weeks Project C code platform integration.hex flash feedback for developers function feedback for software project team HIL testing software integration test function 5
vecu Build Process Inputs Consistent set of modules Dictionary with data types of all variables Os specification. Incremental, fully automated build process. vecu.mdl.m Matlab / Simulink specification for all modules module wrapper generator Module interface data types.mdl wrapped modules Simulink Coder grt.tlc vecu config options C code Os specification build script Calibration data read at run-time Configuration files. 2009-01-1082 6
Discussion Differences between real and virtual ECU A vecu remains a model : not all tests that are relevant can be moved to the PC Zero-time execution: vecu behaves like a device with unlimited computing speed Missing basic software: basic software of the ECU platform is not part of the vecu Different production code: C code is close to but not fully equivalent to production code Many of these differences can be avoided switching to a virtual processor type vecu Runtime performance A virtual ECU for a typical Renault EMS loads & initializes in less than 5 sec. on a Windows PC Execution speed depends on the number of outputs to be recorded during simulation o o Recording170 variables / ms, execution of the vecu is 4 times faster than real time. Recoding 20.000 variables / ms, execution speed is 3 times slower than real time 2009-01-1082 7
3 options to create a vecu vecu is created from models that generate the C code vecu is created from C code compiled for PC Function Developers.mdl.m code generation C code configuration for target CPU Project C code Software Project Team Build vecu for MiL Build vecu for SiL Build vecu for PiL Build for target MCU.hex flash vecu is created from the hex file resulting from compiling C code for the target processor vecu ECU 8
Chip Simulaton Suppliers of ECU hardware and MCUs: to validate their ECU and chip designs (need of cycle accurate platform simulator) OEMs that need to integrate and calibrate supplied EMS software: to run EMS SW on PC when there is access to the hex files, but no access to the C code Function Developers.mdl.m code generation C code configuration for target CPU Project C code Software Project Team However, Hex files for the target MCU become only available weeks after a module edit. vecu Build vecu for PiL Build for target MCU.hex flash vecu is created from the hex file resulting from compiling C code for the target processor ECU 9
SiL type vecu Compared to chip simulation, vecu for SiL runs typically faster and provides better support for C level debugging, if compiled with debug option vecu is created from C code compiled for PC Function Developers.mdl.m code generation C code configuration for target CPU Project C code Software Project Team Build vecu for SiL Build for target MCU.hex However, production C code generator is a shared and limited resource here, not easily available vecu flash ECU 10
MiL type vecu In the automotive world today dominates MBD on PC with MATLAB/Simulink But this does not mean that developers are typically able to simulate their ECU on PC vecu is created from models that generate the C code Function Developers.mdl.m code generation C code configuration for target CPU Project C code Software Project Team Build vecu for MiL Build for target MCU.hex flash vecu The choice is hear to build the vecu from the module source (Simulink.mdl files) ECU 11
vecu Applications Definition of system requirements Completion of environmental model by EMS Module development in system context Bypassing / replacing implementation of module in vecu Pre calibration of the EMS ; frontload calibration related activities Virtual integration of modules before production C code is generated Move selected tests from HiL to MiL Vehicle-level simulation Completion of Digital Electronic Integration PlatForm Validate networked ECUs in vehicle context 12
Move selected tests from HiL to MiL Same plant model Engine Vehicle Gearbox Driver Model Same tests What can be moved? Applicative SoftWare tests What has to stay on HIL? Task scheduling tests of function that combine ASW and BSW runnables Task distribution between cores Advantages Frontloading of automatic tests of applicative functions 1 st Software tests can be done 6 weeks early Faster feedback to function designers More time to correct errors Cost of a vecu is significantly lower compared to cost of a HIL 13
Vehicle-level simulation : Digital Electronic Integration PlatForm DEIPF client DEIPF client DEIPF client DEIPF client (vecu+env.) RT-Lab Orchestra API DEIPF Check of flow coherency between all vehicles ECUs right after model design Intersystem Functional Validation including all vehicle ECUs Issues detection before physical Vehicle Integration Platform tests Increased time on error corrections Lower Cost 14
vecu Applications Definition of system requirements ; completion of environmental model by EMS Module dev. in system context ; bypassing / replacing implementation of module in vecu Pre calibration of the EMS ; frontload calibration related activities Virtual integration of modules before production C code is generated Move selected tests from HiL to MiL Vehicle-level simulation ; completion of a Digital Electronic Integration PlatForm (D-EIPF) to validate networked ECUs in vehicle context 15
I General Purpose I. Introduction II. Interface & Tool III. Example I In 2016, Renault created the 1 st fully functional virtual EMS Process has been repeated for about 6 releases (updates and different platforms) of the EMS software since then Renault started to use virtual ECUs to frontload test and calibration related activities First results of these activities have been encouraging so far Existing MiL-based virtual ECUs will be complemented by SiL-based virtual ECUs 16