CO 2 maîtrisé Carburants diversifiés Véhicules économes Raffinage propre Réserves prolongées Multi-core Simulation of Internal Combustion Engines using Modelica, FMI and xmod Abir Ben Khaled, IFPEN Mongi Ben Gaid, IFPEN Daniel Simon, INRIA Rhône Alpes Nicolas Pernet, IFPEN
2 Outline Introduction, context and motivations Engine modeling using Modelica and models interoperability using FMI Integration and multi-core execution using xmod Test cases and demos Conclusions
3 Context From off-line simulation to real-time simulation Off-line multi-core cosimulation platform Real-time multicore co-simulation platform Control algorithms development (Simulink,...) Controllers or actuators validations Real-time multicore co-simulation platform Physical components models development (OpenModelica, Dymola, AMESim...) virtual Virtual integration et experimentation laboratory Integration of heterogeneous models Validation of physical components on test beds semi-virtual semi-real
Motivations Processors evolution Computational power improvement in today processors is mainly driven by the augmentation of the number of cores per processor Concurrent execution of threads to exploit Thread Level Parallelism (TLP) Core 0 Core 1 Efficient exploitation of resources depends of Splitting applications into tasks Distributed scheduling of tasks Core 2 Core 3 4
5 Motivations Combining real and virtual
6 Motivations Enabling new concepts industrialization Developing new engine concepts that reduce pollutants and consumption requires the ability to simulate, in real-time, the incylinder behaviour (cylinders pressure) Core 0 Core 1 Core 2 Core 3
7 ModEngine library
8 Functional Mock-up interface (FMI) FMI is a set of specifications including FMI for model exchange : describes the software interface of a hybrid ODE (inputs, outputs, parameters, variables, API functions that a solver and an environment needs to call...) FMI for co-simulation : provides a software interface for coupling two or more simulation tools or components, in a master/slave scheme. A slave may be a component integrating both the model and its solver
xmod Concept A platform dedicated to models exploitation Heterogeneous model integration environment Standalone and optimal model exploitation Virtual experimentation laboratory To improve : Model exchange : Having the same tools is no longer necessary to share models improve the collaboration internally and externally 9
10 xmod contributions Proficiency : proficiency in simulation design tools is no longer the "entry ticket" for exploiting simulation Help models exploitation by non expert fields Tools choice : Modeling language choice has less impact on users Congregates the benefits of each tool for each specific application, without having to leave its own tools CPU time : xmod allows a parallel and optimized execution reduce the computation time License cost : model exploitation in xmod does not require any license of the original authoring tools if appropriate export features are used reduce license cost
11 xmod functionalities C C++ A.c B.cpp C. mdl D. ame E.mo F.gtm G.fmu A.xmodel B.xmodel C.xmodel D.xmodel E.xmodel F.xmodel G.fmu A.dll B.dll C.dll D.dll xmod Platform E.dll F.dll
12 xmod functionalities Specific interfaces creation Better simulation workspace customized for each engineering field Easy interactivity with the model in real-time Easy to use exchange vector of models Protect models know how
13 xmod functionalities Compatibility to new Functional Mock-up Interface (FMI) standard standard from MODELISAR project FMI-for-model exchange 1.0 Available solvers in xmod : Euler, Runge-Kutta, DASSL, DASKR, CVODE, LSODAR xmod Solver FMU Model FMI-for-cosimulation 1.0 xmod FMU Model Solver
14 Multi-core co-simulation : approach A B C D E F A B D A B D A B D C C C E F E F E F E F E F E F
Multi-core co-simulation : workflow Decompose the global system into subsystems (preferably with weak coupling) Export each subsystem to an FMU Assemble generated FMUs in xmod Each FMU is executed into a separate thread with a dedicated solver (fixed step or variable step) with a dedicated integration step-size with a dedicated communication step-size A global master ensures proper data transfer during communication points according to a well defined model of computation 15
Engine model splitting Partitioning engine model from a physical point of view Engine Simulator AirPath Minimize the number of discontinuities per subsystem Minimize integration interrupts Minimize interaction dynamics ECU Combustion chamber 1 Combustion chamber 2 Combustion chamber 3 Combustion chamber 4 16
Data exchange overview V a ria ble integ ra tion s tep E ng ine s im ula tor OR Fixed integ ra tion s tep C om m unic a tion s tep E ng ine s im ula tor C om m unic a tion s tep Initia liza tion E xc ha ng e 1 E xc ha ng e 2 17 17 C om m unic a tion s tep E C U C ontroller
F4RT Wiebe test case Test case description Gasoline engine Modeled in Modelica/Dymola using IFPEN library ModEngine Split into 5 subsystems : AirPath + 4 cylinders Combustion chambers models are based on a Wiebe combustion model 500 µs communication step LSODAR used for integrating all split sub-models, except controls LSODAR tolerance = 10-4 Global simulator has 87 state variables and 420 event indicators 18
19 F4RT Wiebe test case Benefits of model splitting and co-simulation Events only here On single core, X2 speed-up Almost no events: Forward integration could performed
20 F4RT Wiebe test case Benefits of model splitting and co-simulation step size = max
Complete Diesel Hybrid vehicle demonstrator Test case description Diesel engine 12 gas model Modeled in AMESim using IFP-Engine library Combustion chambers models are based on Barba phenomenological combustion model Vehicle dynamics modeled in AMESim Complete controls Around 300 state variables 21
Complete Diesel Hybrid vehicle demonstrator Comparative results : Simulink & xmod 22 Using Simulink Requires applying a unique solver and step-size Euler solver with step-size of 25 µs applied to the global system Uses only one core of the machine Using xmod Engine model was split into 5 parts : air path + 4 cylinders Air path is integrated using Euler solver with 100 µs Cylinders are integrated using Euler solver with 25 µs Vehicle model is integrated with RK4 solver with 500 µs Remaining models and controls are run with appropriate solvers and step-sizes (from 500 µs to 100 ms) Results A speedup of X25 was observed on a 6-core machine using xmod wrt Simulink Simulation in xmod is 20% faster than real-time
Conclusion Approach for complex systems simulation Similar speed-up results observed with other engine models This approach was successfully to production models from automotive OEM OpenProd remaining objectives Integrating OpenModelica to this toolchain Linux & Xenomaï compatibility 23