Hev

2003-01-2249

The Development of an Object-Oriented Tool for the Modeling and Simulation of Hybrid Powertrains for Vehicular Applications Steven Wilkins, Michael Lampérth Mechanical Engineering Department, Imperial College London

Copyright © 2003 SAE International

ABSTRACT

INTRODUCTION

The use of computer aided design tools has now proliferated to many areas of engineering and the use of robust and flexible design tools is paramount to modeling complex systems. Hybrid powertrains present often complex systems where simulation and modeling are important issues.

In recent years efforts to reduce polluting emissions created by road transport have increased. This combined with attempts to improve on fuel economy, development of alternative technologies (fuel cells etc.) and reliance on fossil fuels has driven the continued research of hybrid electric vehicles.

This paper presents the development of a simulation tool for the modeling of hybrid powertrains for vehicular applications. The software is developed in Object Oriented code presenting a conceptually intuitive representation of real components.

One of the key aspects of the research into this area is the need for well-designed simulation software due to the complexity of the new concept systems being investigated and their effective design. The majority of simulation packages available are based on fixed powertrain layouts and hence do not allow the exploitation of all the possibilities offered by the hybridization of powertrains.

The importance of matching vehicle design against required drive-cycle is addressed, the various approaches for drive cycles discussed and methodology for making use of GPS data for vehicle simulation presented.

DEFINITION GPS

Global Positioning System

OOL

Optimum Operating Line

LNG

Liquid Natural Gas

PEM

Proton Exchange Membrane

OO

Object-Oriented

GUI

Graphical User Interface

OOM

Object-Oriented Modeling

PREVIOUS AND CONCURRENT WORK Vehicle simulation software has been developed at Imperial College in London for the last decade starting with simulators written in FORTRAN77 [1, 2], then later FORTRAN 90 [3, 4] and Matlab/Simulink [5] with a fixed vehicle and component structure. HEVSIM [4] (1995) can model electric and series hybrid electric vehicles with a flexible powertrain layout. Moreover this code provided the starting point for the backwards-facing iterative solving via ‘cycle feedback’. The code also featured ‘powertrain feedback’ which allowed the automatic resizing of components to meet a drive cycle. Elsewhere, simulators such as SIMPLEV[6], CarSim[7], HVEC[8], CSM HEV[9], Elph/V-Elph[10], ADVISOR[11] & HE-VESIM[12] have all tended towards componentbased codes in Modular languages, albeit with fixed powertrain layouts.

COMPONENT MODELLING AND SIMULATION METHOD The developed code employs different types of models based on experimental data, scripted calculations or empirical models.

GENERALIZED METHOD The simulation tool is based on a network of component models that describe the individual behavior of the vehicle parts. These components are treated in terms of power input and output generally and take onto account the load history as well as transient conditions.

OVERVIEW OF COMPONENTS Simulation Start.

The developed code employs different types of models based on experimental data, scripted calculations or empirical models. A great variety of component models are readily available in the software. Due to open structure, it is very easy to add new components and employing scripting technology this can be done without the requirement to recompile. The scripting uses a simple interpreted language based on BASIC.

Components initialised from input data files.

Demand/Power data files initialised.

Time-Step Read next speed demand from file.

Adjust demanded speed by correction factor.

Component

Read component power outputs.

Calculate power losses.

For electric machine modeling, the simulation code includes models for Electric Motor, Generator and Motor-Generator which use efficiency maps to describe total efficiency in dependence of speed and torque [3]. Generator houses the Optimum Operating Line (OOL). For the modeling of energy storage devices, battery/battery bank model is included based on an empirical model based on a two-tank fluid analogy is employed to represent the non-linear behavior of batteries including transient behavior [13]. Also includes ultra capacitor/capacitor bank based on an iterative solution based on an empirical RC network. Additionally a flywheel model is included based on descriptive formulae are used to describe energy content, inertial and windage losses. [5]

Calculate power input.

YES

Can Component power demand be met?

Cycle Feedback mode?

YES

Find next component.

NO

NO

Final Component in drive-train?

YES

NO Last step in drivecycle? YES

Output results.

Simulation End.

For fuel processors, the simulator includes modeling for engines (Diesel, Gasoline, LNG) and gas turbines [3]. This uses fuel consumption maps to describe total efficiency dependant on output speed and torque. Emission maps are used to predict CO, HC, NOx and particulate emissions [5]. The package also includes modeling for PEM fuel cells using performance maps used to model fuel cell stack performance. [14] Also included are many of the mechanical transmission elements required such as gearbox transmission, which includes a scripted, customizable algorithm for manual or automatic gear changing. This can be used to model driver behavior. The clutch and brake models behave as power-sink components not normally included in vehicle simulations which give insight into the required driver behavior. An important component model included is the modular scripted controller model, allowing linear, switched or fuzzy logic control strategies. Other components include typical transmission elements, and various accessories.

Fig 1 Flowchart Methodology [15]

for

Backwards-Facing

Solution

The majority of simulation codes which exist make use of a backward-facing approach over discrete time-steps [7, 11, 16]. This methodology starts with a known power output from a component, calculates the power losses based on the operating point, and therefore the required power input. The power input of one component is the power output of the previous one in the drive-train, and so using this method the operating points of all the components in the drive-train can be determined. Figure 1 above shows a flowchart for the generalized simulation method used for the majority of codes. The chart includes cycle-feedback which is a backwardsfacing iterative solution when a required vehicle output is not achievable. The main demand parameter for simulation is typically the required vehicle speed, either in form of a drive cycle, or the real-time pedal input. ITERATIVE BACKWARD-FACING DYNAMIC FEEDBACK SOLVING

The majority of components defined are backwardsfacing only; e.g. motor, engine, shaft, batteries. A few of the components however are principally dynamic feedback components. These components require information from any one of the components further up the powertrain path, typically of power supply capacity. The limiting components from each path must communicate their limit back to the feedback component. The commonality for dynamic feedback components is that they require more than one power input and have more unknowns than relationships. Such components include the clutch, brake and controllers. The feedback is illustrated by Figure 2 with calculation starting at the far left component.

COMPONENT

COMPONENT Thick arrows indicating

COMPONENT

convention of power flow

COMPONENT

slow forward-based solution make backwards-iterative by far the most appealing method.

SOFTWARE PROGRESS IN SOFTWARE Object Orientated (OO) modeling and design is a new way of thinking about problems using models organized around real-world concepts [18]. Since the 1980’s the proliferation of Object Orientation as a favored methodology for robust and flexible software design has flourished. In contrast to modular software languages which are grouped based on procedure functionality, OO software focuses more on the grouping of data. Additionally for modular design interaction between modules is hierarchical rather than direct. A vast majority of the simulation packages have been based in the Matlab/Simulink environment which is a modular code.

COMPONENT

Feedback

Fig 2 Schematic of Components in Powertrain with Component Feedback [16] A work-around for these instances can be to formulate relationships for unknowns based on known values. This normally requires an assumption which is often where the model is at its weakest, for example replacing clutch use with a pre-defined profiled clutch application, or frictional brake use being represented by resistance braking in the energy storage device. The feeding-back of component limiting information is an iterative process for each powertrain path, however computation time is reduced by firstly trialing the powertrain limit in a similar range to the previous step. The system demand component itself can also be thought of as a dynamic feedback component. ADVISOR is hybrid vehicle simulator which incorporates a forward-facing solving. In the paper by Wipke et al [11], it is suggested that a forward-facing empirical model is more suitable for maximum acceleration testing where a component is limiting. Forward solving alone is computationally much more costly due to the need for smaller time-steps and higher order integration and therefore less preferable when no component is limiting. ADVISOR compares the required values (backwards-facing results), with achievable values (forward-facing results). This approach requires the definition of two models for each component leading to a large programming overhead for introducing new components. The drawback of the dynamic feedback solution is the increased amount of computation required to find solutions iteratively. However, the reduction in component modeling required and comparison to the

OO software is more than just a tidy method for software design however; it inherently has many properties which are useful in the design of large software packages. These include correctness, robustness, extendibility and reusability which are largely a result of the rigorous design method. STRUCTURE OVERVIEW Object oriented structuring relies on the decomposition of a system into its individual parts, followed by further decomposition of these objects themselves. There are two different forms of this decomposition, that of object decomposition and subject decomposition. This is discussed more by Maffezzoni et al. [19]. Object decomposition of a system reflects the representation of part which reflects the physical components themselves. Subject decomposition makes use of the ability for objects to inherit characteristics from other components. In this way data or functions common to several components can be shared easily and inherited from several other classes. Applying this strategy to the decomposition of a vehicle powertrain into objects implies that by object decomposition, the vehicle’s components involved in the powertrain are directly represented; engine, battery, wheel, transmission etc. Subject decomposition leads to component properties involved in the transmission of power common to all components to be grouped. This leads to the formulation of a base Component class from which all components are derived where common functionality and data are inherited. Figure 3 shows a generalized UML diagram for the code structure.

SYSTEM

creation and destruction of components, the simulation itself, all interaction with the external environment. It manages the linking of components to each other and provides a recursive algorithm to step through component in the correct order during calculation.

COMPONENT

ENGINE

WHEEL

…

Fig 3 Unified Modeling Language (UML) Generalized Representation [16] Component Class: - The Component class holds data and functions common to all objects and provides a common interface between components. The common interfacing is due to the OO feature of polymorphism which enables virtual Component interface functions to be overridden by derived member functions. Where overriding is not required, virtual member functions provide a default handling of component functionality. In reality, an instance of the base class will never exist. Instead only derived classes are used to create the objects which represent the drive-train. System Class: - A System class can be thought of as the container class for a powertrain. It manages the

The System class also performs some important functions which cannot be addressed easily by the components themselves. These include determining the vehicle’s mass, managing the vehicle’s velocity and simulation time-step length. Graphical User Interface: - The Graphical User Interface (GUI) is completely independent of the simulation code. The reason for this strategy is to allow the core of the code to be recompiled as part of other software packages. Currently the GUI will run on any version of Microsoft Windows and features familiar drag and drop functionality. As an important part of the simulation tool, the GUI is able to plot numerous simulation-time plots of information about the vehicle from the virtual CANbus. This is a powerful tool for visualizing at an early stage how a vehicle is performing without a post-processor. Multiple simulations can also be run in parallel for direct comparison. Figure 4 shows a typical simulation window.

Fig 4 GUI Screen Image Showing Example HEV layout [16]

CONTROLLERS This type of modular control has certain advantages over the more conventional centralized controller. Powers at al. [20], observes how control modules can easily be reused, and have features seamlessly added and/or removed. They go on the point out however, that understanding of how these modules can be used in hybrid systems is not fully understood.

Maffezzoni et al [19] give a detailed breakdown of control theory in relation to software structure. They discuss how object-orientated modeling (OOM) forces the modularity of design, separating the mechanism of data exchange from that of control implementation. Additionally it is recognized that recursive aggregation and links amongst objects allows component and subcomponents of a system to be defined for hierarchical control strategies. Further the ‘functional block’ [21] is discussed which has many parallels to what has been developed here.

Controller strategies are user-defined in a script file. This enables the use of linear and switched control strategies as required. The controller has access to the virtual CANbus in order to determine the control strategy. In addition it is a forward-facing component, knowing the power capacity of any power supply paths attached to it.

PARAMETRIC STUDIES

Both these arguments of switch trends and user-defined design performance variables justify the use of scripting for parametric studies. Using the scripting method, a powertrain can be optimized to a viable solution, based exactly on a formulation of the user’s design requirements.

DRIVE CYCLE METHODOLOGY Existing methods for evaluating performance of vehicles are based on standardized drive-cycles which consist of a velocity-time data. In Cycle Feedback mode, simulation programs will calculate the best performance by lowering the vehicle speed from that required when the vehicle is unable to achieve it. If the velocity limits at any point, the vehicle will not travel as far as required by the original cycle. Figure 6 illustrates the effect of Cycle Feedback during a drive cycle.

20

1000 Required Velocity (m/s) Achieved Velocity (m/s) Required Distance (m) Achieved Distance (m)

18 16

Velocity (m/s)

One of the most useful features of the code is the ability to measure a performance variable when altering one or more parameters of components in the simulated vehicle. Typically from a component viewpoint, the resizing of component parameters might be part of a design issue for the development of a new component. However, hybridization of vehicles often features the combination of existing components.

undertaken. The variable may also be a combination of measurements over the cycle with some weighting. [23]

900 800

14

700

12

600

10

500

8

400

6

300

4

200

2

100

0

0

25

50

75

0 100

Time (s)

Fig 6 Deviation of Distance Traveled for Cycle Feedback mode

Fig 5 Statistical Data Mass versus Nominal Torque for Induction Motors. [22] Linear trends for one component parameter against another can be formulated from statistical data. Figure 5 shows real data for how induction motor mass varies with nominal torque. Additionally, trends which involve switched trends either due to commercial or physical limitations of component sizes may also be encountered. An extreme case of this might be where the evaluation of a small number of components is required, where each is considered individually. The design variable for the vehicle performance evaluation may be different for each parametric study

Typically if gradeability or the vehicles performance up an incline is to be considered it is either done as a separate performance evaluation or the grade and velocity data are stated at given time intervals. If for a Cycle Feedback mode simulation the velocity is not met this creates a problem. With linear simulations, if the velocity is not met the time and velocity data can still be linked in that for a given time, the simulation of a given velocity can be attempted. If the grade data is also included this becomes more difficult, since a lower velocity over a given time step implies that a smaller distance over that grade is achieved. Therefore unless time and velocity/grade are unlinked the simulation can change the landscape over which the vehicle is intended to travel in the simulation.

Distance (m)

Controller objects require a degree of configuration by the user due to the complexity of how they can be used. However the intelligent control of hybrid electric vehicles will play a large factor in the development of lowemission, highly fuel efficient vehicles. Increasing use of sophisticated microprocessor-based electronics in more recent vehicles [20] is allowing more elaborate control systems to be implemented. This will no-doubt be an active area of research in the near future.

An alternative way of encapsulating the drive cycle is to base it on positional data, which can also include the grade. Given this approach, two ways of dealing with the Cycle Feedback are possible. The first is to vary the time period over which the step takes place and maintaining the distance vector. The second method is to vary the distance over which the step takes place, in the same direction as the original distance vector. Figure 7 and 8 summarize the differences between the two approaches.

Y Position (m)

30

DISCUSSION The simulation code developed can be used a research or design tool for the evaluation of new concept hybrid electric vehicles. Although initially intended for the sole purpose of simulating hybrid vehicle, there is no apparent limitation to the powertrains which the simulation software can model, using backwards-facing solving methodology. The dynamic feedback method enables components to be included which would conventionally require a forward-facing solution. These components can give insight into driver or external input which is often not included in many typical backwards-facing simulations [11].

20

Vehicle Path Completed Path

Time-Based Methodology:

10

When vehicle speed is limiting, the time step is lengthened for the achieved positional location to match the required positional location.

The minimal amount of code for the introduction of a new component consists of the definition of three functions, due largely to inheritance from the base Component class. The OO design means that the code is intuitively structured with flexible, easy-to-use GUI.

The step is not possible when the time step length time becomes sufficiently large for the component models' validity to break down.

0

0

10

20

30

X Position (m)

The use of a simple scripting implementation extends the user-base for the code, requiring no special programming skills to customize control strategies or parametric analysis.

Fig 7 Time-Based Methodology

A novel way to specify drive-cycles was presented based on position-time data rather than the more traditional velocity-time data. Two methods were indicated which could make use of this data in Cycle Feedback mode owing to the difficulties associated with adjusting the cycle to find the possible velocity.

30

Y Position (m)

points, as does the drive cycle sampling, the number of points would need to be sufficiently high when large positional changes occur.

20

REFERENCES Vehicle Path Completed Path

1. Liebenberg, L., A.L. Nel, and K.R. Pullen. Computer simulation of electric-, gas turbine-, and gas turbine hybrid electric vehicles, SAE technical paper number 941733. in SAE International Off-Highway and Powerplant Congress and Exposition. 1994. Milwaukee, Wisconsin: Society of Automotive Engineers (SAE).

Distance-Based Methodology:

10

When vehicle speed is limiting, the distance travelled in the time step is decreased, but the time step time length is preserved so that the achieved time step end time matches the required. Proceeding steps' velocities are taken from the required velocity based on position. Required time step end postions are then taken from linear interpolation from the path between points

0

0

10

20

30

X Position (m)

Fig 8 Distance-Based Methodology The distance-based methodology provides simulation points at the same time stepping as the original data which would be more useful for direct comparison, since any real data is more likely to be at fixed sampling rate. Since the simulation assumes linear movement between

2. Yaxas, Y., Hybrid vehicle simulation, in Mechanical Engineering. 1994, Imperial College, University of London: London. 3. Leontopoulos, C., Vibration analysis for the design of a turbo-generator based powertrain for hybrid vehicles. 1997. 4. Lampérth, M., Pullen, K. Turbogenerator based hybrid versus dieselelectric hybrid - a parametric optimisation simulation study. in SAE Future

Transportation Technology Conference. 2000. Costa Mesa, California: SAE. 5. Lefebvre, F., Modelling and simulation of conventional and hybrid vehicles, in Mechanical Engineering. 1999, Imperial College, University of London: London. 6. Cole, G.H., SIMPLEV; A simple electric vehicle simulation program, version 2.0. 1993, EG&G Idaho Inc.: Idaho. 7. Cuddy, M. A comparison of modeled and measured energy use in hybrid electric vehicles, SAE technical paper number 950959. in SAE International Congress and Exposition. 1995. Detroit, Michigan: Society of Automotive Engineers (SAE). 8. Aceves, S.M. and J.R. Smith. A hybrid vehicle evaluation code and its application to vehicle design, SAE technical paper number 950491. in SAE International Congress and Exposition. 1995. Detroit, Michigan: Society of Automotive Engineers (SAE). 9. Braun, C. and D. Busse. A modular Simulink model for hybrid electric vehicles, SAE technical paper number 961659. in SAE Future Transportation Technology Conference and Exposition. 1996. Vancouver, Canada: Society of Automotive Engineers (SAE). 10. Butler, K.L., K.M. Stevens, and M. Ehsani. A versatile computer simulation tool for design and analysis of electric and hybrid drive trains, SAE technical paper number 970199. in SAE International Congress and Exposition. 1997. Detroit, Michigan: Society of Automotive Engineers (SAE). 11. Wipke, K., Cuddy, M., Burch, S., ADVISOR 2.1:A User-Friendly Advanced Powertrain Simulation Using a Combined Backward/Forward Approach. 1994, National Renewable Research Laboratory. 12. Lin, C., et al., Integrated, Feed-Forward Hybrid Electric Vehicle Simulation in SIMULINK and its Use for Power Management Studies. SAE Society of Automotive Engineers, 2001. 13. Lampérth, M., Simulation of Hybrid Electric Vehicle, in Mechanical Engineering. 1996, Imperial College: London.

CONTACT Email: [email protected], [email protected] URL: http://www.HybridPower.org

14. Mistry, S., Modelling Fuel Cell Behaviour for Vehicle Performance Simulation. 2001, Imperial College, University of London: London. 15. Pangalis, M.M.-B., R; Brandon,N, Integration of solid oxide fuel cells into gas turbine power generation cycles, Part 1: fuel cell thermodynamic modelling. Journal of Power and Energy, 2002. 216. 16. Wilkins, S., A. Walker, and M.U. Lampérth, Robust Software Strategy for Powertrain Modelling. 2002, Imperial College: London. 17. Butler, K.L., M. Ehsani, and P. Kamath, A Matlab-based modeling and simulation package for electric and hybrid electric vehicle design. Ieee Transactions on Vehicular Technology, 1999. 48(6): p. 1770-1778. 18. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W, Object-oriented modelling and design. 1991, NJ, USA: Prentice-Hall. 19. Maffezzoni, C., Ferrarini, L., Carpanzano, E., Object-oriented models for advanced automation engineering. Control Engineering Practices, 1999. 7: p. 957-968. 20. Powers, W., Nicastri, P, Automotive vehicle control challenges in the 21st century. Control Engineering Practice, 2000. 8: p. 605-618. 21. Standard-IEC-1499, Function Blocks for Industrial-Process Measurement and Control Systems. 1996, IEC TC65/WG6. 22. Mueller, K.G., Life Cycle Assessment in Engineering Design, in Mechanical Engineering. 2000, Imperial College, University of London: London. 23. Hellgren, J. and B. Jacobson. A systematic way of choosing driveline configuration and sizing components in hybrid vehicles, SAE technical paper number 2000-01-3098. in SAE Future Transportation Technology Conference and Exposition. 2000. Costa Mesa, California: Society of Automotive Engineers (SAE).