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 One of the key aspects of the research into this area is
tool for the modeling of hybrid powertrains for vehicular the need for well-designed simulation software due to
applications. The software is developed in Object the complexity of the new concept systems being
Oriented code presenting a conceptually intuitive investigated and their effective design. The majority of
representation of real components. simulation packages available are based on fixed
powertrain layouts and hence do not allow the
The importance of matching vehicle design against exploitation of all the possibilities offered by the
required drive-cycle is addressed, the various hybridization of powertrains.
approaches for drive cycles discussed and methodology
for making use of GPS data for vehicle simulation PREVIOUS AND CONCURRENT WORK
presented.
Vehicle simulation software has been developed at
DEFINITION Imperial College in London for the last decade starting
with simulators written in FORTRAN77 [1, 2], then later
GPS Global Positioning System FORTRAN 90 [3, 4] and Matlab/Simulink [5] with a fixed
vehicle and component structure. HEVSIM [4] (1995)
OOL Optimum Operating Line can model electric and series hybrid electric vehicles
with a flexible powertrain layout. Moreover this code
LNG Liquid Natural Gas provided the starting point for the backwards-facing
iterative solving via ‘cycle feedback’. The code also
PEM Proton Exchange Membrane featured ‘powertrain feedback’ which allowed the
automatic resizing of components to meet a drive cycle.
OO Object-Oriented
Elsewhere, simulators such as SIMPLEV[6], CarSim[7],
GUI Graphical User Interface HVEC[8], CSM HEV[9], Elph/V-Elph[10], ADVISOR[11]
& HE-VESIM[12] have all tended towards component-
OOM Object-Oriented Modeling based codes in Modular languages, albeit with fixed
powertrain layouts.
COMPONENT MODELLING AND SIMULATION GENERALIZED METHOD
METHOD
The simulation tool is based on a network of component
The developed code employs different types of models models that describe the individual behavior of the
based on experimental data, scripted calculations or vehicle parts. These components are treated in terms of
empirical models. power input and output generally and take onto account
the load history as well as transient conditions.
OVERVIEW OF COMPONENTS
Components initialised from
Simulation Start. input data files.

The developed code employs different types of models

based on experimental data, scripted calculations or Demand/Power data files
empirical models. A great variety of component models initialised.

are readily available in the software. Due to open

Time-Step
structure, it is very easy to add new components and Read next speed demand from
file.

employing scripting technology this can be done without Adjust demanded speed by
the requirement to recompile. The scripting uses a correction factor.

simple interpreted language based on BASIC. Component Read component power outputs.

Calculate power losses.

For electric machine modeling, the simulation code
includes models for Electric Motor, Generator and Calculate power input.

Motor-Generator which use efficiency maps to describe YES

total efficiency in dependence of speed and torque [3].

Generator houses the Optimum Operating Line (OOL). Can Component power
demand be met?
Cycle Feedback mode?

For the modeling of energy storage devices, YES

NO

battery/battery bank model is included based on an Find next component. NO Final Component in
empirical model based on a two-tank fluid analogy is drive-train?

employed to represent the non-linear behavior of YES

batteries including transient behavior [13]. Also includes NO

Last step in drive-
ultra capacitor/capacitor bank based on an iterative cycle?

solution based on an empirical RC network. Additionally YES

a flywheel model is included based on descriptive Output results.

formulae are used to describe energy content, inertial
and windage losses. [5] 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 for Backwards-Facing Solution
Methodology [15]
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 backwards-
facing 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 backwards-
facing 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
Thick arrows
COMPONENT
indicating
COMPONENT convention of
power flow
COMPONENT 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
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.
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 COMPONENT
… The System class also performs some important
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
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.
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.
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.
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 sub-
components 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 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 low-
emission, 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.
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
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.
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
undertaken. The variable may also be a combination of
measurements over the cycle with some weighting. [23]
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
18 Required Velocity (m/s) 900
Achieved Velocity (m/s)
16 Required Distance (m) 800
Achieved Distance (m)
14 700
Velocity (m/s)
Distance (m)
12 600
10 500
8 400
6 300
4 200
2 100
0 0
0 25 50 75 100
Time (s)
Fig 6 Deviation of Distance Traveled for Cycle
Feedback mode
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.
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.
30
20
Y Position (m)
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 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
X Position (m)
Fig 7 Time-Based Methodology
30
20
Y Position (m)
Vehicle Path
Completed Path
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 2.
0 10 20
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
points, as does the drive cycle sampling, the number of
points would need to be sufficiently high when large
positional changes occur.
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].
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.
30
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.
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.
REFERENCES
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).
Yaxas, Y., Hybrid vehicle simulation, in
30
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: sw8@ic.ac.uk, m.lamperth@ic.ac.uk
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).