An Object-Oriented Modelling Tool of Hybrid Powertrains for Vehicle

Performance Simulation
S. Wilkins, M. U. Lampérth

Abstract

This paper covers the development of a robust, flexible, multi-configuration software tool for the
modelling of powertrains of conventional and hybrid vehicles.

Modern programming techniques allow greater flexibility and reuse of code as well as an intuitive way
of modelling physical components in software. The proposed methodology for software modelling
makes use of the core features of modern object-oriented code, combined scripting for control
strategies and user defined parametric analysis. Controllers and the increasing trend towards modular
control is then discussed.

Verification of the software is then made against real hardware batteries in a simulated vehicle,
showing the correlation between measured and simulated data. Copyright © 2002 EVS19

Keywords: Simulation, Powertrain, HEV (hybrid electric vehicle), Optimization, Controller,

Battery Management.

1. Introduction

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 have driven the continued research of hybrid electric vehicles.
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.

1.1. 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 component-based codes in Modular
languages, albeit with fixed powertrain layouts.
2. Component Modelling and Simulation Method

The developed code employs different types of models based on experimental data, scripted
calculations or empirical models.

2.1. Overview of Components

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.

The major components are listed below:

Electric Motor, Generator, Motor-Generator : Uses efficiency maps to describe total efficiency in
dependence of speed and torque [3]. Generator houses an Optimum Operating Line (OOL).

Battery/Battery Bank: An empirical model based on a two-tank fluid analogy is employed to represent
the non-linear behaviour of batteries including transient behaviour [13]

Engine (Diesel, Gasoline, LNG), Gas Turbine [3]: 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]

Flywheel: Descriptive formulae are used to describe energy content, inertial and windage losses. [5]

Ultra Capacitor/Capacitor Bank: Iterative solution based on an empirical RC network.

Fuel Cell (PEM): Performance maps used to model fuel cell stack performance. [14]

Gearbox Transmission: Scripted, customisable algorithm for manual or automatic gear changing. This
can be used to model driver behaviour.

Clutch/Brake: Power-sink components not normally included in vehicle simulations which give
insight into the required driver behaviour.

Controller: Modular scripted controller, allowing linear, switched or fuzzy logic control strategies.

Generic Component: Fully scripted component which allows the user to define a component without
recompiling the code or any detailed knowledge of programming.

Other components include Wheel [5], Shaft, Differential Transmission and Accessories.

2.2. Generalized Method

The simulation tool is based on a network of component models that describe the individual behaviour
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.
 Components initialised from
Simulation Start. 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.

Calculate power input.

YES

Can Component power

Cycle Feedback mode?
demand be met?

YES
NO

Find next component. NO Final Component in

drive-train?

YES

NO
Last step in drive-
cycle?

YES

Output results.

Simulation End.

Figure 2.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 2.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.
2.3. 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.2 with calculation starting at the
far left component.

COMPONENT COMPONENT
Thick arrows
indicating
COMPONENT convention of
power flow

COMPONENT COMPONENT

Feedback

Figure 2.2 Schematic of Components in Powertrain with Component Feedback [15]

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 trialling 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 modelling required and comparison to
the slow forward-based solution make backwards-iterative by far the most appealing method.
3. Software

3.1. Progress in Software

Object Orientated (OO) modelling and design is a new way of thinking about problems using models
organized around real-world concepts [17]. Since the 1980’s the proliferation of Object Orientation as
a favoured 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.

3.2. 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. [18].

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.1 shows a generalised UML diagram for the code structure.

SYSTEM COMPONENT

ENGINE WHEEL
…

Figure 3.1 Unified Modelling Language (UML) Generalised Representation [15]

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

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.

Utility Classes: - One of the most important classes from a control viewpoint is that of the CANbus
class to mimic a real CANbus (SAE J1939 Standard). Data about the condition of every component in
the powertrain is placed on a virtual CANbus. This can then be used by any component which requires
either active control of other components, or to passively receive information in order to set its own
state.

The Effmap class is a generic class for the management of either 2D or 3D maps. It provides much of
the common interpolation code necessary for reading from map data points. Additionally it manages
smoothing edges of regions of operation of the component.

There are a number of other classes and sub-classes to deal with file management, vehicle demand
management, scripting and solution states.

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 3.2 shows a typical simulation window.

Figure 3.2 GUI Screen Image Showing Example HEV layout and Dialog Box [15]
3.3. Controllers

This type of modular control has certain advantages over the more conventional centralised controller.
Powers at al. [19], 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 [18] give a detailed breakdown of control theory in relation to software structure.
They discuss how object-orientated modelling (OOM) forces the modularity of design, separating the
mechanism of data exchange from that of control implementation. Additionally it is recognised 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’ [20] 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 [19] 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.

3.4. 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.

Figure 3.3 Statistical Data Mass versus Nominal Torque for Induction Motors. [21]

Linear trends for one component parameter against another can be formulated from statistical data.
Figure 3.3 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. [22]

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 optimised to a viable
solution, based exactly on a formulation of the user’s design requirements.
4. Simulation Example and Verification

Comparison of results of existing simulators was essential, but the verification of the simulation
against a real-world powertrain was considered invaluable. A series-hybrid go-kart was tested in-situ
on a rolling road in the laboratory; a simple vehicle to enable easy instrumentation. Figure 4.1 shows
the layout of the vehicle as seen in the graphical user interface of simulation.

Figure 4.1 Software Representation of Powertrain.

The powertrain consists of a 3.5 hp Briggs & Stratton IC engine as the Prime Mover Unit (PMU)
linked via a chain to a PMG132 permanent magnet generator. Four Hawker SBS 30 thin-plated lead
acid batteries are employed as the Energy Storage Device (ESD) and a 4QD controller then controls
the power in to the permanent magnet 8.5 kW Lynch traction motor. The control strategy is based on
maintaining the DC bus voltage that link controller, ESD and PMU.

An investigation was undertaken to compare the performance the vehicles performance to a demand-
speed step input, with predicted data from the simulation model. Measurements were taken of all
electrical parameters for batteries, PMU and traction motor, with the data-acquisition system also
recording vehicle speed. A very good agreement was found between the simulation and experimental
data with errors generally below 5%. Figure 4.2 shows the predicted and experimental battery voltage
for the maximum acceleration experiment.
 65

60

55

Voltage [V] 50

45

40
Measured Battery Voltage
Simulated Battery Voltage
35

30
0 10 20 30 40 50 60 70
Time [s]

Figure 4.2 Graph of Simulated and Measured Battery Voltage for Go-Kart Maximum Acceleration
5. 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.

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.

Verification against real hardware shows some initially promising results, although the refinement of
component models is an ongoing process. Since the code only relies on backwards-facing models only
and no forward-facing, the amount of work required for each refinement is reduced.
6. 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).

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.

14. Mistry, S., Modelling Fuel Cell Behaviour for Vehicle Performance Simulation. 2001, Imperial
College, University of London: London.

15. Wilkins, S., A. Walker, and M.U. Lampérth, Robust Software Strategy for Powertrain Modelling. 2002,
Imperial College: London.

16. 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.

17. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W, Object-oriented modelling and
design. 1991, NJ, USA: Prentice-Hall.

18. Maffezzoni, C., Ferrarini, L., Carpanzano, E., Object-oriented models for advanced automation
engineering. Control Engineering Practices, 1999. 7: p. 957-968.

19. Powers, W., Nicastri, P, Automotive vehicle control challenges in the 21st century. Control Engineering
Practice, 2000. 8: p. 605-618.

20. Standard-IEC-1499, Function Blocks for Industrial-Process Measurement and Control Systems. 1996,
IEC TC65/WG6.

21. Mueller, K.G., Life Cycle Assessment in Engineering Design, in Mechanical Engineering. 2000,
Imperial College, University of London: London.
22. 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).

7. Affiliation

Mr. Steven Wilkins

Researcher in hybrid powertrain modelling focusing on HEVs, simulation software techniques

and hardware-the-loop simulation. Has performed studies on onboard energy storage
devices and electric braking, heavy vehicle subsystems. E-mail: sw8@ic.ac.uk

Hybrid Power Research Group, C.A.S.E., Department of Mechanical Engineering, Imperial

College of Science, Technology & Medicine, London, Tel: +44-20-7594-7024/0 Fax: +44-
20-7584-7239 URL: http://www.me.ic.ac.uk/hybridpower/

Dr. Michael Lampérth

Lecturer of Design, CAD, Electronics and Instrumentation in the Department of Mechanical

Engineering of Imperial College, London. He is head of the hybrid power research group which
focuses on sustainable energy technologies, hybrid electric vehicles, including simulation, and
permanent magnet machines. E-mail: m.lamperth@ic.ac.uk

Hybrid Power Research Group, C.A.S.E., Department of Mechanical Engineering, Imperial

College of Science, Technology & Medicine, London, Tel: +44-20-7594-7024/0 Fax: +44-20-
7584-7239 URL: http://www.me.ic.ac.uk/hybridpower/