real time simulation of complex automatic transmission models · real time simulation of complex...

1

Real Time Simulation of Complex Automatic Transmission Models

Marius Băţăuş, Andrei Maciac, Mircea Oprean, Nicolae Vasiliu


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 cus-tomer 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 tradi-tional 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 in-creasing 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 ex-ample high altitude, incorrect settings or changes due to parts wear. For AT an ade-quate 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. Supplemen-tary 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 de-tailed hydraulic control circuit is possible.

The highly detailed AT models are developed and tested offline using LMS Imag-ine.Lab AMESim (AMESim) a 1D multi-domain simulation platform. AMESim gen-erates 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.


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 itera-tions, 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 espe-cially 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;


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 plat-form (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 af-fect 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 dedi-cated components libraries that can be use for modelling and simulation of power-trains 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 in-volved 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 pos-sible 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 8.1.3 using Matlab/Simulink/RTW 2006b;

– RTLab 8.0.5 using Matlab/Simulink/RTW R14sp3;

– dSPACE 5.0 using Matlab/Simulink/RTW R14sp3;


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 rela-tively 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 simu-lation 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 accelera-tion profile for a global AT model and for a physical mechanical model, figure 2.


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 devel-oped 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 con-verter, 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).


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 consump-tion 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 fre-quencies. For the AT models the sensitive submodels are those of the torque con-verter, 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 condi-tions. However, since the fluid dynamics processes inside the torque converter are substantially faster than the typical time constants of the vehicle longitudinal dynam-ics, 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 imple-mented 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


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 fric-tion 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 de-mands.

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 compo-nents 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 consid-ering the given recommendations. The initial model is considered to be well struc-tured. 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


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 compari-son 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 ob-tained with the standard solver. When the step is increased to 0.7 ms some integration noise can be seen especially in the 3rd and 5th 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 compo-nents. 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.


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 discon-tinuities (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 dis-continuity. 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 variable-step 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 communi-cation interval values, it is impossible to appreciate the recovery difficulties. Never-theless this analysis is essential for non-linear systems since the user know what time to choose for the linearization to get the limiting eigenvalues.


11

Figure 8. Plot of step size during variable-step simulation

The eigenvalues facility is useful to determine system dynamics. In our case the ei-genvalues 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 Ii is not zero)

– stable integration of full damped modes (imaginary part Ii is zero)

– stable and no oscillating integration of full damped modes (zero imaginary part Ii)

Where:

– fi is the frequency of the i mode (Hz)

– Ri is the real part of the i mode

– Ii is the imaginary part of the i mode

– fE is the Euler fixed step solver frequency

Because the problems were identified in the 3rd and 5th gears the linear analysis is per-formed at two corresponding linearization times. The following necessary solver fre-quency was determined:

22 / 2E i if f R

E if R

/ 2E if R


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 0.324 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 eigenval-ues 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 ex-ample it was sufficient to change 3 parameters in order to decrease the needed integra-tion frequency at 1934 Hz. Model results are checked to verify if these changes mod-ify 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)


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 distribu-tion towards the different receivers (clutches and brakes). It serves as an interface be-tween 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 simplifi-cation is necessary and the model must be detailed in function of the study require-ments. The focus is on the gear change control and therefore the pressure regulators


14

are simplified. Also, for the first level the hydraulic circuit of the torque converter in-cluding 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 hydrau-lic 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 electro-hydraulic valves. Figures 13 and 14 shows the vehicle longitudinal acceleration pro-file 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.


15

Figure 12. RT model of Renault DP0 transmission

Figure 13. Vehicle longitudinal acceleration profile and actuators pressure variations for incor-rect settings of valves commands

Figure 14. Vehicle longitudinal acceleration profile and actuators pressure variations for correct settings of valves commands


16

Engine models

The engine model is chosen in function of the application type. For the developed ap-plication the most simple are those base on look-up tables. When a more complex en-gine 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 de-tailed 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 en-gine 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 con-trol unit model) using AMESim-Simulink interface blocks. Figure 15 shows the Simulink model used for the export. It contains: AMESim S function block, a com-mand panel, a simplified model of the TCU and models of sensors and actuators.

Figure 15. Control System model (Simulink)


17

The model can be controlled manually, based on a commands cycle or based on a ve-locity 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 con-trol, 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 de-fined 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 pre-processed in the initialization phase of the simulation. Unit conversion will also influ-ence 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.


18

The entire graphical user interface is implemented with dSPACE ControlDesk. Well struc-tured layouts, partly with photorealistic visualization, enable the user to interact with the sys-tem 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 con-trol 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


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 simula-tions (e.g. prerequisites, model restrictions, parameter tuning and model testing). Guidelines of how to construct detailed physical models of AT are given and their ef-ficiency is demonstrated on two detailed models, including one with detailed model-ling 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 de-signed 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 com-fort and fuel consumption studies. These validated benchmark models make it easier


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/01.10.2007), POSDRU/6/1.5/S/19 contract (ID_7713/2007) and by EU through project Marie Curie MTKI-CT-2005-029775.

References

1. Alirand, M., Jansson, A., Debs, W. , "A First Idea of Continuity in Model Simpli-fications for Hydraulic Circuit – An Automatic Gearbox Real-Time Application", SICFP’05, June 1-3, Linkoping, Sweden, 2005

2. 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, 2008

3. Băţăuş, M., Maciac, A., Oprean, M., Andreescu C., Vasiliu, N., "Real Time Simu-lation of Drivetrain Launch Devices", Paper 1078, CONAT 2010

4. 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.264-281

5. 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.93-114

6. Miller, S., Wendlandt, J., "Real-Time Simulation of Physical Systems Using Sim-scape", MATLAB News and Notes, January 2010

7. 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, 1997

8. Pichon, Y, "The Interest of AMESim to Model Global System for Control Design-ers", Global Powertrain Congress' 2000, Detroit, USA.

9. Weeks, R., Moskwa, J., "Automotive Engine Modeling for Real-Time Control Us-ing MATLAB/SIMULINK," SAE paper No. 950417, 1995

10. * * * "Real-Time Simulation with AMESim", Rev 8A – June 2008

real time simulation of complex automatic transmission models · real time simulation of complex...

Documents