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.
Simulation Start.
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.
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
Last step in drivecycle?
NO
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 (backwardsfacing 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 demandspeed 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
Voltage [V]
55 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 OffHighway 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. 17701778.
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:
[email protected] 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: +4420-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:
[email protected] 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-207584-7239 URL: http://www.me.ic.ac.uk/hybridpower/
