Real Time Simulation of Complex Automatic Transmission Models. Marius Băţăuş, Andrei Maciac, Mircea Oprean, Nicolae Vasiliu

Transcription

1 Real Time Simulation of Complex Automatic Transmission Models Marius Băţăuş, Andrei Maciac, Mircea Oprean, Nicolae Vasiliu 1

2 Introduction To manage the function of a vehicle s engine, transmission, and related subsystems, almost all modern vehicles make use of an electronic control system. This powertrain control system continues to become more complex in order to meet the increased customer expectations and tightening environmental regulations. The development cycle of electronically controlled mechanical devices can be speed up using hardware-in-the-loop (HiL) simulation. For powertrains, this replaces traditional testing environments such as real vehicles or powertrain dynamometers that are often expensive, time-consuming, and subject to variability. Modern electronically controlled automatic transmissions (AT) employ logic features of the implemented software to provide good performance and shift quality over a wide operating range. New control algorithms and calibrations techniques are used to meet permanently increasing comfort standards regarding the gearshift of AT. This is a typical application for which the use of HiL simulation has a big impact. In order to cope with real-time simulation constrains, only rough models are often used. However studies show that it is possible to use detailed models of modern AT, [7], [1]. Such models allow the testing of electronic control units under simulated conditions that would otherwise be very expensive or awkward to reproduce, for example high altitude, incorrect settings or changes due to parts wear. For AT an adequate physical mechanical model can also provide good efficiency estimation. A high level of modelling of the transmissions permits also to study the influence of comfort improving control strategies (e.g. clutch slipping) on fuel consumption. Supplementary difficulties appear when a detailed model of the Electrohydraulic Control Unit (EHC) is required since the usual hydraulic component models are not adapted for real-time simulation, [1]. This paper aims to present typical modelling of AT and real-time simulation issues involved in these applications. Models of key components (hydraulic control circuit, clutches, brakes, torque converter etc) adapted for real-time are discussed and their use is integrated in a full powertrain model adapted for comfort and fuel consumption studies. The results presented demonstrate that a real-time simulation of AT with detailed hydraulic control circuit is possible. The highly detailed AT models are developed and tested offline using LMS Imagine.Lab AMESim (AMESim) a 1D multi-domain simulation platform. AMESim generates C code that can be use in Simulink and by use of Real-Time Workshop can be downloaded on different HiLS targets. A dspace platform was used in order to evaluate the benchmark problems and to demonstrate the real-time performance of complex powertrain models. 2

3 Real-time simulation demands To turn an offline plant & control model into a real-time model is necessary to ensure that the plant model runs with fixed step solver. This can make real-time simulation more challenging than desktop simulation. Usually some simplifications should be done but with good understanding of real-time needs simplifications can be kept small. Moreover, for a simulation to execute in real-time, the amount of time spent calculating the solution for a given time step (execution time) together with the amount of time spent processing inputs, outputs, and other tasks must be less than the length of that time step. It is necessary to leave sufficient safety margin to avoid an overrun when simulating in real-time, figure 1, [6]. Figure 1. The constrains of the step size for real-time simulation To move from desktop simulation to real-time simulation on the chosen real-time hardware, the following items can be adjusted: solver type, number of solver iterations, step size, model size and fidelity. The challenge is to find appropriate settings that provide accurate results (results sufficiently close to the results obtained from desktop simulation) while permitting real-time simulation. Recommendations for this process are given in [6]. Base on the authors experience, when using AMESim to develop a powertrain model for real-time applications the following steps are recommended: 1. Build a standard AMESim model and test it with variable step solver; 2. Modify the model considering the specific recommendations for real-time (e.g. use only submodels proven for real-time simulation, reduce the number of states especially the ones with higher dynamic) and validate the model; 3. Adjust the parameters in order to work with fix step solver and test it in AMESim; 4. Connect the model with the Simulink using AMESim-Simulink interface blocks and test the model using the desired fix step solver from Simulink; 3

4 5. Build an appropriate user interface for the real-time application, generate the code for real-time, load it to the real-time platform and connect the interface to the platform (if necessary). The first step is not mandatory. It allows testing very detailed models and can be use as a validation tool. It is also recommended if the use of real-time submodels can affect the results. If sufficient validation data exist it can be skipped. Prerequisites Typically the development of a plant model for real-time application implies the use of more than one software packages. Today different software packages offer dedicated components libraries that can be use for modelling and simulation of powertrains and many support real-time simulation (AMESim, Dymola, SimulationX etc). Nevertheless Simulink is the preferred environment for control system design and code generation for real-time applications (using Real-Time Workshop). Different software is needed to control the real-time platform and a supplementary experiment environment can be use. All aspects regarding software compatibility and configurations must be considered before the project is started. It is advisable to firs test every software packages involved and the compatibility and interfaces between them. In the studied cases the models were developed in AMESim and exported on a dspace RT platform using Real-Time Workshop from Simulink. Therefore is essential to check the versions compatibility and test the interfaces between: 1. AMESim-Simulink; 2. Simulink-dSPACE; 3. AMESim-Simulink-dSPACE. Every software developer provides compatibility tables but generally not all the possible combinations are fully tested. Also specific C compilers are needed for different operating platforms (e.g. UNIX, Linux, Windows). AMESim real-time package depends on several different software packages. This makes it impossible to support all potential configurations. For example AMESim Rev 8A is tested with: RTLab using Matlab/Simulink/RTW 2006b; RTLab using Matlab/Simulink/RTW R14sp3; dspace 5.0 using Matlab/Simulink/RTW R14sp3; 4

5 dspace 6.0 using Matlab/Simulink/RTW R2007b; xpc Target using Matlab/Simulink/RTW/xPC R2007b. Other configurations may work. The files that are version-dependent are normally the template makefiles (TMF) used by Real-Time Workshop, [10]. Aspects regarding installation directories and setting of environment variables must be considered. Because of the complexity of this process it is strongly recommended to use simple models to test the installations and configurations. Model development A high level of physical fidelity is generally necessary to represent a complete system like an AT and this can only be achieved by detailed analysis. A multidomain system (hydraulic, mechanical and electro-mechanical) usually contains a significant number of components. Today s software packages used for simulation enable to construct models that include many details. However for real-time application it can be relatively difficult to simplify a very detailed model since it is as complex to understand as the real system. In such a case guidelines and help are very appreciated even for experienced engineers. The work is simplified by using dedicated component libraries provided by the simulation software like AMESim. This is a complete virtual system analysis platform that allows users to design multi-domain systems and provides advanced tools to study the static/dynamic behaviour of any component or system. For that the model can be simulate in real-time is compulsory to: Use submodels compatible with real-time; Simplify the model (reduce the number of states); Use adequate parameters for real-time in order to limit the system dynamic. Gearshift dynamics can only be simulated if the input and output torques of the transmission represent a real-life vehicle manoeuvre. Therefore, at least the engine and the longitudinal dynamics of the vehicle have to be modelled beside the AT. Transmission modelling Detailed models of AT are more fitted than global ones for the study of control strategies for the coupling elements. This can be seen when comparing the longitudinal acceleration profile for a global AT model and for a physical mechanical model, figure 2. 5

6 Figure 2. Longitudinal acceleration profile obtained with a global and with a physical AT model For AT with planetary gear sets a physical mechanical model can also provide good efficiency estimation. The use of variable efficiency is important for fuel consumption studies due to the high variation of the transmission input torque and speed during a driving cycles. Such a high level of modelling of the transmissions permits also to study the influence of comfort improving control strategies (such as clutch slipping) on fuel consumption. Figure 3 shows the sketch and the gear selection matrix of a typical 6-gear automatic transmission based on Lepelletier mechanism. The model of the powertrain is developed for the first time for offline simulation to test the capability of the model to run with fixed step solver and the accuracy of the results. This is a compulsory step taken before the generation of the real-time model. It allows the parameters optimization in order to obtain good results with fixed step solver and to see the limit of the model in terms of integration method and time step value. The model includes a physical mechanical model of the gearbox: inertia, torque converter, lock-up clutch, planetary gear sets (with basic elements for the Ravigneaux gear set), clutches and brakes, bearing loss models and final drive (figure 4). 6

7 Figure 3. Structure of a typical automatic gearbox Figure 4. Advanced model of a 6 gear Lepelletier transmission with speed dependant losses Similar transmission models are useful for offline simulation both for fuel consumption and comfort studies but simulation of such detailed models in real-time poses special problems. The model has to be checked to verify it doesn't contain submodels that generate at any time: huge constant time values, singularities or high modal frequencies. For the AT models the sensitive submodels are those of the torque converter, clutches and brakes. For the torque converter is possible to use either static or dynamic models. The static models employ steady-state performance curves and are valid in steady-state conditions. However, since the fluid dynamics processes inside the torque converter are substantially faster than the typical time constants of the vehicle longitudinal dynamics, the fluid dynamic effects may often be neglected. In connection with impeller and turbine inertias they are usual valid for up to 10 Hz frequency. Most of the static models use the capacity factor ([8], [4]) but for real-time simulation must be used models based on MP2000 factor, [3]. Accurate torque converter dynamic models can extend the frequency range up to 50Hz. A detailed dynamic model [5] was implemented in the standard AMESim Powertrain library and it demonstrate good results when tested with fix step solver [3]. The model s 18 parameters, most of them giving 7

8 the torque converter internal geometry (e.g. inlet and outlet angles of impeller, turbine and stator) make it difficult to use. Other problems are related to the way in which the friction is modelled. Some friction models generate important time constant values and for some applications cannot be solve with fix step solver. The clutches and brakes are based on different types of friction models: hyperbolic tangent, Dahl, LuGre, Karnopp and reset-integrator. Due to the simplicity users prefer the hyperbolic tangent model. Even that this friction model can be used for real-time modelling of the start-up clutches (for manual transmissions) [1], they prove not suited for AT clutches and brakes [3]. Extended tests demonstrate that the reset-integrator models are the most adequate for real-time simulations demands. The number of stiffnesses and inertias has to be limited as far as possible. In this way is avoided the use of inertia components with small inertia value or stiffness components with big stiffness values that generate the highest modal frequencies. If a start model developed for variable step solver exists it has to be modified considering the given recommendations. The initial model is considered to be well structured. The models of lock-up clutch and the multi-disk clutches and brakes A, B, C, D and E are changed with RT compatible ones. After one model is modified for RT simulation it must be validated. Usually this is done using the original model. To simulate gearshift dynamics at least the engine and the longitudinal dynamics of the vehicle have to be modelled. Figure 5 shows an AMESim global powertrain model developed for gear shifting comfort studies. Figure 5. AMESim powertrain model for gear shifting comfort studies 8

9 This model is used both to analysis system dynamics and as reference for the next real-time models. By comparing the results obtained with the standard robust variable step solver with those obtained with different fix step solvers and integration steps is possible to appreciate if the model can work with fix step solver. Because it takes time to compare all results the most relevant ones are selected. Figure 6 shows a comparison of the longitudinal acceleration of the vehicle obtained with different solvers and integration step sizes (Euler integrator with 0.5 and 0.7 ms step size). Figure 6. Longitudinal acceleration of the vehicle for different solvers and integration steps Results of the Euler solver with 0.5 ms step are almost identical with the ones obtained with the standard solver. When the step is increased to 0.7 ms some integration noise can be seen especially in the 3 rd and 5 th gears. Integration step of 0.5 ms seems satisfying. Nevertheless a deeper analysis shows that instability can occur in this case. When looking at the flywheel acceleration obtained with the 0.5 ms step, an integration noise can be observed, figure 7. This noise is not propagated to the vehicle acceleration because it is filtered by the driveline components. However in particular situations this could lead to a divergent model. Usually two methods are employed to investigate the model in a rigorous manner: step size and eigenvalues analysis. 9

10 Figure 7. Engine rotary acceleration obtained for Euler solver with 0.5 ms step Examine the step sizes during the simulation allow to determine if the model is likely to run with a large enough step size to permit real-time simulation. A variable-step solver will vary the step size to stay within the error tolerances and to react to discontinuities (zero crossing events). If the solver abruptly reduces the step size to a small value (e.g. 1e-15s), this indicates that the solver is trying to accurately identify a discontinuity. A fixed-step solver may have trouble capturing these events at a step size large enough to permit real-time simulation. In AMESim using Run statistic is possible to access the time step value that was used to converge during the simulation, figure 8. This facility allows evaluating at what stage is the problem the stiffest and gives an indication regarding the fix step size to be use. For an experienced user the amount of discontinuities (zero-crossing events) and how easily the simulation recovers give a rough indication of how difficult it will be for a fixed-step solver to produce accurate results at the largest step size that the variablestep solver uses, [6]. This appreciation can be done more easily when Simulink is used. Due to the large results files in AMESim, a communication interval must be set. By selecting the option to print the discontinuities it can be appreciated the number of discontinuities and the most frequent step size values but, with reasonable communication interval values, it is impossible to appreciate the recovery difficulties. Nevertheless this analysis is essential for non-linear systems since the user know what time to choose for the linearization to get the limiting eigenvalues. 10

11 Figure 8. Plot of step size during variable-step simulation The eigenvalues facility is useful to determine system dynamics. In our case the eigenvalues analysis enables to determine the maximum step for the fixed step solver. For Euler fixed step solver the following conditions have to be verified at any time to have stable integration, [2]: stable integration of undamped modes (imaginary part I i is not zero) 2 2 / 2 f f R E i i stable integration of full damped modes (imaginary part I i is zero) f stable and no oscillating integration of full damped modes (zero imaginary part I i ) f E E R /2 R Where: f i is the frequency of the i mode (Hz) R i is the real part of the i mode I i is the imaginary part of the i mode f E is the Euler fixed step solver frequency Because the problems were identified in the 3 rd and 5 th gears the linear analysis is performed at two corresponding linearization times. The following necessary solver frequency was determined: i i 11

12 882 Hz for stable integration of the worst undamped mode; 3078 Hz for stable integration of the worst full damped mode. From here it is possible to conclude that a solver step of 0.5 ms (or solver frequency of 2000 Hz) is not sufficient to guarantee the stability of the system. Is possible to: Use a step of ms that ensures the solver stability with the current parameters; Simplify the model; Modify the parameters in order to limit the system dynamic. Because the model is well designed and a 0.5 ms step size is desired it is compulsory to modify the original parameters. It is advisable to use software tools to identify the components involved in the highest dynamic of the system. By tuning the parameter values of these elements it is possible to decrease the system dynamics and then to run the model with a bigger step value. The dynamics corresponding to limiting eigenvalues can be identified by using the modal shape facility. More easy is to use the state count facility to identify the states that lead to most time consuming integrations. Important parameters in our example are stick displacement threshold and viscous damping parameters for friction models using reset integrators (as clutches and brakes). Increased stick displacements generate slower dynamics. Small viscous damping reduces the constant time of the generated dynamics. Also, good results can be achieved by increasing the moments of inertia of the rotary loads. For the given example it was sufficient to change 3 parameters in order to decrease the needed integration frequency at 1934 Hz. Model results are checked to verify if these changes modify significantly the model outputs. On the vehicle longitudinal acceleration the error appears to be insignificant (figure 9). Figure 9. Longitudinal acceleration of the vehicle for different parameters (standard integrator) 12

13 Electrohydraulic Control Unit model To fully test the control software or the Transmission Control Unit (TCU) a detailed model of Electrohydraulic Control Unit (EHCU) must be added to the transmission. The hydraulic circuit comprises the elements of pressure regulation and oil distribution towards the different receivers (clutches and brakes). It serves as an interface between the calculator and the mechanism. Its roles are: to pilot the clutches and the brakes, to pilot the converter lock-up, to ensure the flow rate and pressures necessary for the good working of the AT, to feed the torque converter circuits, the lubrication and cooling circuits. The EHCU is a complex unit composed from pressure regulators, hydraulic valves, distributors, accumulators, check valves and calibrated orifices. A typical example of EHC is that of the Renault DP0 transmission, figure 10. Figure 10. Complete hydraulic circuit of the DP0 automatic gearbox For the real-time models it is important to maintain a low complexity, [1]. A simplification is necessary and the model must be detailed in function of the study requirements. The focus is on the gear change control and therefore the pressure regulators 13

14 are simplified. Also, for the first level the hydraulic circuit of the torque converter including the lock-up clutch control is ignored. The model include the hydraulic valves A, B, C, D, P and Q, the pressure accumulator, the lines, the calibrated orifices and the hydraulic actuators, figure 11. The most complex elements of the system are the hydraulic valves. The low mass of the spools and the high stiffness will induce a high dynamics. Since the usual hydraulic component models are not adapted for real-time simulation a new piston model is used. Classical piston models need the spool position variable at ports. The new piston model includes the velocity integration to suppress the need of the mass model, [2]. The use of the new models is not restricted to RT application. They are optimized for speed and allow running complete systems faster while keeping a good accuracy of the results. Figure 11. Model of the DP0 automatic gearbox hydraulic circuit When integrated with a transmission model (figure 12) in a global powertrain model for gear shifting comfort studies is possible to optimize the commands of the electrohydraulic valves. Figures 13 and 14 shows the vehicle longitudinal acceleration profile and the actuators pressure variations obtained with different delays between valves commands. The step size needed for a correct simulation using Euler solver is 0.3 ms. 14

15 Figure 12. RT model of Renault DP0 transmission Figure 13. Vehicle longitudinal acceleration profile and actuators pressure variations for incorrect settings of valves commands Figure 14. Vehicle longitudinal acceleration profile and actuators pressure variations for correct settings of valves commands 15

16 Engine models The engine model is chosen in function of the application type. For the developed application the most simple are those base on look-up tables. When a more complex engine control is needed it is possible to use mean torque predictive models that are physically base but relative simple and give good results when incorporated into detailed powertrain or vehicle dynamics systems, [9]. It is also feasible to use models that predict individual cylinder filling phenomena. Such a model developed in AME- Sim was successful integrated in a global powertrain model containing the 6 gear AT previously presented. The work has been started from an already tested real-time engine model. The step size needed for a correct simulation using Euler solver is the minimum step size employed before on the engine model (0.15 ms). Model export on RT platform The export on RT platform is done using Real-Time Workshop from Mathworks. Therefore the powertrain model is first connected with a Simulink model (e.g. a control unit model) using AMESim-Simulink interface blocks. Figure 15 shows the Simulink model used for the export. It contains: AMESim S function block, a command panel, a simplified model of the TCU and models of sensors and actuators. Figure 15. Control System model (Simulink) 16

17 The model can be controlled manually, based on a commands cycle or based on a velocity cycle. To allow the last type of control a speed profile map and a driver have been added. A Simulink variable step solver that gives accurate results is selected and test are done for the new functionalities (e.g. driving on a velocity cycle, figure 16). The model is tested with the desired fix step solver and step size. Typically this pose no problems because the model was tested before in AMESim using open loop control, figure 17. Figure 16. Demonstration of Velocity Imposed Cycle Figure 17. Vehicle longitudinal acceleration profile for different Simulink solvers The parameters and variables that must be accessed on the RT platform have to be defined previous to generate the code for real-time target. Some restriction can occur. For AMESim models this functionality can t be used with pre-processed parameters. Many AMESim parameters are not used directly in the calculation since they are preprocessed in the initialization phase of the simulation. Unit conversion will also influence the parameters. When the submodel uses the conversion to SI units the parameter or variable you access will be expressed in SI units, [10]. Real-time simulation results The models were simulated in real-time with adequate sample rates on the dspace RT platform equipped with ds1006 processor board (2.6 GHz). The results show maximum turnaround times small enough to allow the implementation of complex control software for the transmission. 17

18 The entire graphical user interface is implemented with dspace ControlDesk. Well structured layouts, partly with photorealistic visualization, enable the user to interact with the system and manage the real-time experiments, figure 18. The developed models can be use for transmission control software to development and calibration. A simple interface for the control of the electrohydraulic valves is used in order to study the gearshift sequence, figure 19. Figure 18. Graphical user interfaces implemented in ControlDesk Figure 19. Interface for the control of the electrohydraulic valves The gearshift valve operating sequence is critical for AT gearshift comfort. Figure 20 shows typical simulation results for a powertrain equipped with AT obtained on a dspace RT platform using a detailed AT model that includes the EHCU. The gear change acceleration profile from 1 to 2 under Wide Open Throttle (WOT) is improved using a better command for the coupling elements. Figure 20. Improvement of acceleration profile by better control of coupling elements 18

19 The same model can be used for fuel consumption studies. Figure 21 shows the fuel consumption and the engine operating points obtained when an imposed driving cycle is follow. Figure 21. Fuel consumption and engine operating points for an imposed driving cycle Conclusions In this paper it was described typical issues that occur in powertrain real-time simulations (e.g. prerequisites, model restrictions, parameter tuning and model testing). Guidelines of how to construct detailed physical models of AT are given and their efficiency is demonstrated on two detailed models, including one with detailed modelling of the hydraulic control circuit. Simulations results show some of the potential in using of these models: 1. As non-real-time models for offline testing of the transmission control algorithms it is possible to develop new control algorithms without the hardware constrains and software complexities of running in real-time. Because the models are designed to be fast even that they maintain a high level of fidelity may be incorporate into large powertrain or vehicle dynamics models without a substantial increase of simulation time. 2. As real-time AT models for HiL testing the models may be used to evaluate the performance of transmission control software, controllers, sensors and actuators. It can be integrated with detailed engine models and use to test the entire powertrain control network. The AT models were integrated in a full powertrain real-time model adapted for comfort and fuel consumption studies. These validated benchmark models make it easier 19

20 for researcher and control engineers to evaluate newly developed control algorithms in a very direct and repeatable mode. Acknowledgements The work was supported by CNCSIS of Romania through project ID_1091 (contract number 166/ ), POSDRU/6/1.5/S/19 contract (ID_7713/2007) and by EU through project Marie Curie MTKI-CT References 1. Alirand, M., Jansson, A., Debs, W., "A First Idea of Continuity in Model Simplifications for Hydraulic Circuit An Automatic Gearbox Real-Time Application", SICFP 05, June 1-3, Linkoping, Sweden, Băţăuş, M., Gallo, F., Ripert, P.J., "Real-Time Simulation of Detailed Powertrain Models", Advanced Transmissions for Low CO2 Vehicles, June 4, Paris, France, Băţăuş, M., Maciac, A., Oprean, M., Andreescu C., Vasiliu, N., "Real Time Simulation of Drivetrain Launch Devices", Paper 1078, CONAT Hong, C.W., "An Automotive Dynamic Performance Simulator for Vehicular Powertrain System Design", Int. J. of Vehicle Design, Vol. 16, No. 2/3, 1995, pp Hrovat, D., Tobler, W.E., "Bond Graph Modeling and Computer Simulation of Automotive Torque Converters", J. Franklin Inst., Vol. 319, No. 1/2, 1985, pp Miller, S., Wendlandt, J., "Real-Time Simulation of Physical Systems Using Simscape", MATLAB News and Notes, January Otter, M., Schlegel, C., Elmqvist, H., "Modeling and Realtime Simulation of an Automatic Gearbox using Modelica", 9th European Simulation Symposium and Exhibition Simulation in Industry, Passau, Germany, October 19-22, Pichon, Y, "The Interest of AMESim to Model Global System for Control Designers", Global Powertrain Congress' 2000, Detroit, USA. 9. Weeks, R., Moskwa, J., "Automotive Engine Modeling for Real-Time Control Using MATLAB/SIMULINK," SAE paper No , * * * "Real-Time Simulation with AMESim", Rev 8A June