i
Analysis Tool for Fuel Cell Vehicle Hardware
and Software ( Controls) with an Application to Fuel Economy Comparisons
of Alternative System Designs
By
Karl- Heinz Hauer
Dipl. Ing. ( University of Braunschweig, Germany) 1990
Dissertation
Submitted in partial satisfaction of the requirements for the degree of
Doctor of Philosophy
in
Transportation Technology and Policy
in the
Office of Graduate Studies
of the
University of California
Davis
Approved:
Committee in Charge
2001
ii
Meinem Vater
iii
Table of Content
1. INTRODUCTION AND PROBLEM CONTEXT .................................................................... 1
2. LITERATURE REVIEW........................................................................................................ 5
2.1. Introduction................................................................................................................... ................... 5
2.2. Survey and Discussion of the existing vehicle models .................................................................. 11
2.2.1. The HY- ZEM ( Hybrid- Zero Emission Mobility) Model .......................................................... 14
2.2.2. The PNGVSAT ( Program for New Generation Vehicles Systems Analysis Toolkit) Model... 18
2.2.3. The Advisor ( Advanced Vehicle Simulator) Model ................................................................. 26
2.2.4. The UC- Davis Hydrogen ( 1998 Version) Model...................................................................... 32
2.2.5. The Simplev ( Simple Electric Vehicle Simulation) Model....................................................... 36
2.3. Summary........................................................................................................................ ................. 38
3. APPLIED MODELING METHODOLOGY .......................................................................... 44
3.1. General Aspects........................................................................................................................ ...... 44
3.2. Mathematics ............................................................................................................................... .... 46
3.2.1. Introduction................................................................................................................... ........... 46
3.2.2. Example and Transfer into SIMULINK.................................................................................... 56
4. MODEL DESCRIPTION...................................................................................................... 58
4.1. Modeling Structure and Goals....................................................................................................... 58
4.2. Vehicle Model.......................................................................................................................... ....... 60
4.2.1. Drive Cycles and Driver Model ................................................................................................ 61
4.2.2. Physical Vehicle Model ............................................................................................................ 66
4.3. Component Models ......................................................................................................................... 73
4.3.1. Electric Motor Including Power Electronic .............................................................................. 73
4.3.2. Motor Controller and Motor Control Algorithm....................................................................... 82
4.3.3. Transmission................................................................................................................... ......... 90
4.3.4. Fuel Cell System....................................................................................................................... 94
4.3.5. Battery System........................................................................................................................ 128
4.3.6. Ultra- Capacitor System........................................................................................................... 140
4.3.7. DC- DC Converter ................................................................................................................... 154
4.3.8. Vehicle Controller................................................................................................................... 173
5. MODEL APPLICATION.................................................................................................... 179
5.1. Vehicle Requirements................................................................................................................... 179
5.2. Vehicle Parameters and Vehicle Design...................................................................................... 181
5.3. Component Sizing ......................................................................................................................... 189
5.3.1. Choice and Sizing of the Battery System................................................................................ 189
5.3.2. Choice and Sizing of the Ultra- capacitor System ................................................................... 191
iv
5.4. Simulation Results ........................................................................................................................ 197
5.4.1. Load Following Fuel Cell Vehicle Model............................................................................... 198
5.4.2. Battery Hybrid Fuel Cell Vehicle Model ................................................................................ 207
5.4.3. Ultra- Capacitor Hybrid Fuel Cell Vehicle Model ( indirect coupling) .................................... 221
5.4.4. Ultra- Capacitor Hybrid Fuel Cell Vehicle Model ( direct coupling) ....................................... 228
5.5. Summary of the Simulation Results ............................................................................................ 234
6. VERIFICATION OF THE RESULTS................................................................................. 239
7. SUMMARY AND CONCLUSION ..................................................................................... 245
8. REFERENCES.................................................................................................................. 249
9. APPENDIX....................................................................................................................... 255
9.1. Forwards and Backwards Looking Modeling Approach .......................................................... 255
9.2. Method of Co- Simulation ............................................................................................................. 261
9.3. Rapid Prototyping.................................................................................................................... .... 267
9.4. Conversion Factors ....................................................................................................................... 268
9.5. Vehicle Parameters ....................................................................................................................... 269
9.6. Battery and the Battery Controller Parameters......................................................................... 271
9.7. Ultra- Capacitor Parameters for the Directly to the Stack Coupled Ultra- Capacitor............. 272
9.8. Ultra- Capacitor Parameters for the Via Dc- Dc Converter to the Stack Coupled Ultra-
Capacitor ............................................................................................................................... ................... 274
1
1. Introduction and Problem Context
The ever- growing demand for individual transportation leads to a larger and
larger vehicle fleet and a steady increase in vehicle miles traveled ( VMT) ( National
Research Council, 1997). Associated with this increase in VMT are increases in air
pollution and carbon dioxide emissions, one possible reason for the observed global
warming phenomena ( The International Panel on Climate Change, 1995). Although
emissions from new conventional vehicles with internal combustion engines and hybrid
vehicles with internal combustion engines and additional electric motors are reduced, the
air quality standards are not in attainment with federal regulations in many regions in the
United States. Especially on the west coast in California with its rapid growth, booming
economy, and special weather conditions that promote the formation of ozone, cities like
Los Angeles and San Diego battle severe air quality problems ( Lloyd, 1999). In addition,
the energy efficiency and related carbon dioxide emissions are still far from the 80
miles/ gallon goal for passenger vehicles set by the Partnership of New Generation
Vehicles ( PNGV) and seem to be difficult to achieve with conventional technology.
Widely discussed among the alternatives to the internal combustion engine
vehicle are fuel cell vehicles. This vehicle type promises not only very clean operation
( up to zero emission operation, but also higher energy efficiency than conventional
vehicles without the range limitations associated with battery electric vehicles. 1 Although
the fuel cell vehicle has been discussed since the 60’ s ( Sievert 1968), fuel cell vehicles
have not been seen as a likely replacement for the internal combustion engine vehicle
until recently. In 1994 Daimler Chrysler ( formerly Daimler Benz) introduced the first
2
New Electric Car ( NeCar 1) in a series of five prototype fuel cell vehicles ( Daimler
Chrysler 1999). Despite the fact that these vehicles have prototype characteristics they
demonstrated one path to a more environmentally friendly passenger vehicle and sparked
public interest and a race into the market. Today all major car companies are investing
heavily in this new and promising technology with ambitious plans to introduce it into the
market ( Panik 1999, GM Europe 1999).
Fuel cell vehicle modeling is one method for systematic and fast investigation of
the different vehicle options ( fuel choice, hybridization, reformer technologies).
However, a sufficient modeling program, capable of modeling the different design
options, is not available today. Shortfalls of the existing programs, initially developed for
internal combustion engine hybrid vehicles, are:
• Insufficient modeling of transient characteristics;
• Insufficient modeling of advanced hybrid systems;
• Employment of a non- causal ( backwards looking) structure;
• Significant shortcomings in the area of controls.
Modern simulation programs should be capable of serving as tools for analysis as
well as development.
In the area of analysis, a modeling tool for fuel cell vehicles needs to address the
transient dynamic interaction between the electric drive train and the fuel cell system.
Especially for vehicles lacking an instantaneously responding on- board fuel processor,
this interaction is very different from the interaction between a battery ( as power source)
1 Besides hydrogen fueled fuel cell vehicles, battery electric vehicles are the only other zero emission
technology available today.
3
and an electric drive train in an electric vehicle design. Non- transient modeling leads to
inaccurate predictions of vehicle performance and fuel consumption.
Applied in the area of development, the existing programs do not support the
employment of newer techniques, such as rapid prototyping. This is because the program
structure merges control algorithms and component models, or different control
algorithms are lumped together in one single control block and not assigned to individual
components as they are in real vehicles. In both cases, the transfer of control algorithms
from the model into existing hardware is not possible.
The simulation program developed in this dissertation recognizes the dynamic
interaction between fuel cell system, drive train and optional additional energy storage. It
provides models for four different fuel cell vehicle topologies:
• A load following fuel cell vehicle;
• A battery hybrid fuel cell vehicle;
• An ultra- capacitor hybrid fuel cell vehicle in which the ultra- capacitor unit is
coupled via a dc- dc converter to the stack;
• An ultra- capacitor hybrid fuel cell vehicle with direct coupling between fuel cell
stack and ultra- capacitor.
The structure of the model is a causal and forward- looking. The model separates
the modeling of control algorithms from the component models. The setup is strictly
modular and encourages the use of rapid prototyping techniques in the development
process.
4
The first half of the dissertation explains the model setup. In the second half of the
dissertation, the simulation of different hybrid vehicle designs illustrates the capabilities
of the model.
This study shows that, from the standpoint of fuel economy improvement, hybrid
fuel cell vehicles have a potential advantage over the pure load- following fuel cell
vehicle. Further, the study shows that among the modeled hybrid vehicles the vehicle
with directly to the stack coupled ultra capacitor shows the largest benefit in terms of fuel
economy compared to the pure load- following design. An additional benefit of this
design is that it is the simplest of the three investigated hybrid vehicle concepts.
For all of the analyzed hybrid vehicles, the improvement of fuel economy results
from the ( averaged over a drive cycle) higher fuel cell system efficiency and the
additional feature of regenerative braking. Besides the arrangement of the components,
the realized fuel economy benefits depend significantly on the control schemes balancing
vehicle performance, fuel cell system characteristics, and stress of the energy storage
system. Due to the limited energy storage capacity of the ultra capacitor systems, the two
vehicles hybridized with ultra capacitors are especially sensitive to the design of the
control algorithms.
In addition to the potential improvement of fuel economy, hybrid designs offer
the possibility to relax the transient requirements for the fuel cell system and the feature
of a rapid cold start in the morning ( increased customer benefit). Although not
investigated, each of these two advantages is considered important and could, together
with the higher fuel economy, spark the interest in hybrid fuel cell vehicle designs in the
near future.
5
2. Literature Review
This chapter analyses different fuel cell vehicle models and compares them with
each other on a qualitative basis. Quantitatively Hoefgen ( Hoefgen 2001) compares a
subset of the models listed in Table 2- 3. For the qualitative comparison in this
dissertation work first a metric of comparison was established. Second the most
commonly discussed models are listed and relationships are identified. Based on the
metric of comparison five of the listed modeling programs are described and advantages
and disadvantages are highlighted. The comparison concludes that none of the
investigated models is satisfactory in terms of modularity ( separation of controls and
component models), vehicle configurations modeled, and dynamic capabilities.
2.1. Introduction
The generic requirements for a fuel cell fuel vehicle model can be defined as
follows and are not different to the requirements of other types of modeling work2.
A fuel cell vehicle model has to be physically and mathematically sound. All
relevant physical effects have to be considered and the model should stand on
mathematical solid ground. Unless these two conditions are fulfilled we cannot rely on
the results. In addition to the soundness the scope of the model should also be complete.
Complete in this context means that it should enable the modeling of different types of
vehicles ( hybrids, non hybrids and different forms of hybrids) and fuel cell systems for
different fuels. The resolution of the modeling effort should be high enough to capture all
the effects of interest. For example some of the models listed in Table 2- 3 simplify the
6
function of regenerative braking so much that the results become extremely inaccurate. In
the context of Table 2- 1, the resolution or depth of modeling these models provide is not
sufficient. Also a fuel cell vehicle model has to be flexible enough to incorporate new
trends and technologies without the need of starting from scratch. From a practical point
of view: the necessary input data have to be available, the validation of the model should
be possible, and the model should support its use as well as the issue of program
maintenance. The runtime should be in context of the problem setup. Therefore for more
complex questions a longer runtime seems to be acceptable. Last, but not least, the results
have to be valid and ( within tolerances) match the experimental results.
• Theoretically sound
o Physically
o Mathematically
• Complete scope
o Consideration of different vehicle and fuel cell system concepts
o Resolution ( are all effects of interest modeled in a sufficient detail)
o Flexibility ( is the model flexible enough to incorporate future
developments)
• Practicality
o Are the required input data available?
o Validation possible?
o Ease of operation
o Ease of program maintenance? ( Logical structure)
o Runtime
• Valid results
Table 2- 1: Generic modeling requirements
2 The listed requirements are basically taken from John L. Bowman and Moshi Ben – Akiva’s paper
“ Activity - Based Travel Forecasting” ( Bowman and Akiva, 1996) but translated into the context of this
dissertation work.
7
Requirement Criteria
Theoretical soundness Is the model programmed in a forward or backwards
approach? 3
Complete Scope
• Completeness
Is the model employing techniques supporting the coverage of
a wide range of vehicle concepts ( scaling, component
libraries)? 4
• Resolution Does the model support the method of co- simulation?
• Flexibility Is the model programmed in a modular way? 5
Practicality
• Input data
Are all required input data available?
• Validation Does the program setup support the method of rapid
prototyping?
Are component models separated from control algorithms?
• Ease of use Is a graphical user interface programmed?
Is the documentation complete and useful?
Is the runtime reasonable?
Is the setup of the model transparent and logical?
Valid results All the models investigated in this paper deliver valid results
within tolerances. Therefore this requirement is not a measure
of comparison.
Table 2- 2: Translation of the original requirements into objective criteria that could be checked
For an objective comparison of the different simulation models the list of
requirements in Table 2- 1 is not beneficial. Therefore the content of Table 2- 1 is
translated into a number of key criteria that a “ good” fuel cell vehicle- modeling program
3 Limiting the requirement of theoretical soundness to the criteria above assumes that the model does not
violate any elementary physical or mathematical laws. This assumption is justified for all of the models
looked at in this dissertation.
4 The issue of completeness looks towards the potential of a model to be complete, e. g.; the coverage of all
vehicle configurations of interest. Because of the number of possible configurations and the
unpredictability of future developments completeness is fulfilled if the model structure supports measures
to incorporate a large number of designs.
8
has to fulfill ( Table 2- 2). The comparison is looking at these criteria assuming that the
incorporation of them into the program guarantees the original requirements in Table 2- 1.
This systematic comparison emphasizes the ( theoretical) potential of the simulation
programs. This first comparison will be supported by a closer look at how much of the
theoretical potential has already been realized in the current version of each model. This
second measure of comparison is more subjective because of fact that due to the very
different modeling approaches a direct comparison of functionality is not possible.
However it still provides significant insight into the current state of fuel cell vehicle
modeling.
After establishing the method of comparison the following paragraphs list the
most important ( and most used) electric, hybrid and fuel cell vehicle modeling programs.
Among them only the UC- Davis hydrogen fuel cell vehicle model has been exclusively
developed for fuel cell vehicle modeling. All the other programs incorporate functionality
for the simulation of battery electric and IC hybrid vehicles.
5 Flexibility describes the possibility to change the model structure in a time efficient manner. A modular
structure supports flexibility.
9
Table 2- 3: Overview about alternative fuel vehicle models
In addition to the vehicle models listed in Table 2- 3 other models are under
development or already completed. Most of these other, not listed, models are either
propriety and internally developed by automotive manufacturers or contractors and only
very limited information is publicly available or they are not completed yet. For this
reason these models are not discussed in this dissertation work.
The next section compares the most important models listed in Table 2- 3 with
regard to the criteria explained in the appendix and derives, based on this comparison, the
need for a new vehicle model that will be described in this dissertation work.
The comparison ends in a summery and concludes that a new fuel cell vehicle
model is necessary.
Name Source Backwards/
Forwards
Fuel
Cell
Vehicles
?
Year
HYZEM Ricardo Consulting
Engineers Ltd.
Forward No 1995
Elvis Southwest Research
Institute
Backwards No 1993
Path Southwest Research
Institute
Forward No 1996-
1997
PSAT Southwest Research
Institute and
Argonne National
Laboratories
Forward Yes 1996-
1999
Advisor National Renewable
Research
Laboratory ( NREL)
Backwards Yes 1994-
2000
Simplev Idaho National
Engineering and
Environmental
Laboratory
Backwards No 1990-
1997
Avte UC- Davis, ITS Backwards No 1996
UC Davis – Hydrogen UC- Davis, ITS Backwards Yes 1999
10
The appendix provides the necessary background information about three major
issues associated with fuel cell vehicle modeling. They are closely tied to the list of
model requirements at the beginning of the chapter and have their origin in this list.
The issues discussed in the appendix are:
• The choice of the modeling approach. Two different modeling approaches have been
realized in the existing fuel cell vehicle models. The forwards looking and the
backwards looking approach. The physical and mathematical soundness of the model
is significantly depending on the choice of the modeling approach.
• The incorporation of co- simulation techniques. Co- simulation techniques are the
parallel operation of two different modeling programs, e. g. Matlab/ Simulink for the
overall vehicle and Saber for the electric drive train within the vehicle. Co-
Simulation allows a higher depth of modeling or a higher resolution.
• The incorporation of rapid prototyping and hardware in the loop features. Both
methods are well known development techniques for shortening the development
time. From a modeling point of view the benefits are the fact that ( through the
involvement of the simulation program in the development process) a mutual
validation of the model at all development stages occurs, and not only at the end of
the development process.
11
2.2. Survey and Discussion of the existing vehicle models
Five different development lines could be identified looking at the model
properties and the historical development of the models ( Figure 2- 1). These are:
• Ricardo Consultants with the Hyzem program system ( Heath, 1996 and Sadler, 1998).
• Southwest Research Institute ( SWRI) with the modeling program systems Elvis, Path,
Apace and their final product PSAT ( McBroom, 1996). PSAT has been originally
developed as the modeling tool for the Partnership of New Generation Vehicles but
will be soon made publicly available from Argonne National Laboratory for
registered researchers6.
• National Renewable Energy Institute with the program system Advisor ( National
Renewable Energy Laboratories, 2000). Since recently, Argonne National
Laboratories is responsibility for the development lines PSAT and Advisor and
incorporates them into a single graphical user interface for the ease of use.
• UC- Davis starting originally with the Advanced Vehicle Test Emulator ( AVTE) and
an ( AVTE based) direct hydrogen fuel cell vehicle model ( Fuel Cell Modeling Group,
1999). Both models are derived from Advisor. In addition to this modeling effort,
UC- Davis started within the fuel cell vehicle modeling project a new forward looking
fuel cell vehicle model that incorporates currently the fuels hydrogen, indirect
methanol and indirect gasoline in hybrid and non- hybrid versions.
6 The release, for registered researchers only, is scheduled for November 2000.
12
• Idaho National Engineering and Environmental Laboratory ( INEEL) with Simplev.
The program has only historical meaning - it was phased out in 1997 ( Idaho National
Engineering and Environmental Laboratory, 1993).
The final product of each of these development lines will be taken and
benchmarked according to the criteria listed in Table 2- 2. In addition the fuel cell vehicle
modeling capabilities will be listed qualitatively, e. g.; which type of fuel cell vehicle
models are included ( hybrids, fuel choice).
Finally a statement about the current stand of the model with respect to depth of
analysis will be made. For example, some of the vehicle models include a static fuel cell
system model based on maps only while other models take dynamic aspects into account.
Based on this comparison it will be concluded that a new fuel cell vehicle
simulation model is necessary.
13
Elvis
1990 1995 2000
Path Psat
Apace
Hyzem
Simplev
Generation 1- 3
Advisor
Generation 1- 3
Avte DH2
INEEL
IMFCV
NREL
UC- Davis
SWRI
Ricardo
merge
4 models
remain
Argonne
National
Lab.
Figure 2- 1: Model evolvement and history
14
2.2.1. The HY- ZEM ( Hybrid- Zero Emission Mobility) Model
HY- ZEM has been programmed by Ricardo Consultants and is not commercially
available as an off the shelf programming package7. The program will always be
delivered in a project specific form as part of a development contract. The model is
programmed in Simulink in a causal, forward looking, approach ( Heath, 1996, Sadler,
1998). Figure 2- 2 shows the program setup ( highest level) for the example of a series
hybrid electric vehicle with internal combustion engine.
The presence of a “ driver” block indicates the forward- looking approach. Besides
the driver the model consists of one main control Block “ SH controller” and component
blocks for every major component.
Each component model has three input and three output ports, each port could
also be vectorized meaning it could combine several individual variables. The inputs and
outputs are listed in Table 2- 4. Control inputs and outputs are signals with no energy
associated with them for example the value of a voltage or a current. Power
outputs/ inputs connect blocks on the physical level. One example is the battery voltage
connected to the motor block. This connection is physical and could therefore be seen in
a real vehicle. The third pair of inputs/ outputs is also a physical connections but through
these connections feedback loops among components are established. One example for
such a feedback loop is the feedback of the motor current to the accessory block and
finally to the battery block. Through these feedback loops dynamic behavior is
incorporated into the model. Hyzem is set up in a modular form and includes a library for
mechanical, electrical and control modules that all employ the same input / output
7 Personal email exchange with Ricardo Consultants in October 2000
15
structure ( Heath 1996). Input data for the modeling process are standard vehicle
parameters and steady state maps for operating point dependent component properties
( Sadler, 1998).
Input/ Output Label Comment
Input 1 Controls input Signals from the controller
block
Input 2 Power input Input values from a
previous block
Input 3 Feedback input Feedback values from a
connected block
Output 1 Controls output Signals looped to the
controls block
Output 2 Power output Output values to a
succeeding block
Output 3 Feedback output Feedback values to a
connected block
Table 2- 4: Overview of component models inputs and outputs.
No information could be found about the possibility of co- simulation. However in
principle the causal, forward looking, approach supports co- simulation. Also the program
package “ wave” ( Ricardo Consultants, 2000) has been suggested by Ricardo Consultants
to UC- Davis for modeling the airside of a fuel cell system. Because of this suggestion it
could be assumed that Ricardo also combines ( or attempts to combine) Hyzem and
wave8.
Because of the fact that the model is not off the shelf available, and is only
provided as part of a larger contract, the issue of “ ease of use” becomes secondary. For
example a graphical user interface, complete documentation and straight logic is not
essential if the user gets assistance from Ricardo. The model has been validated with a
Volkswagen Golf IC- hybrid vehicle and a Peugot 106 electric vehicle ( Heath, 1996).
8 Personal email exchange between members of the fuel cell modeling group ( UC- Davis) and Ricardo
16
Modeling results for an indirect methanol fuel cell vehicle in load following and
load leveling ( hybrid) form have been presented by Sadler ( Sadler, 1998). The model
includes start up characteristics and emissions although it is not clear how detailed the
model is9.
Strengths:
• Strong modular approach using predefined components from a library ( Heath, 1996),
• The model considers the dynamic interaction ( feedback) between components ( Heath,
1996).
Weaknesses:
• The combination of the library modules leads to a difficult to oversee system
diagram, which does not always reflects the causalities within the vehicle. ( Example:
In the electric vehicle model the battery voltage does not directly feed back into the
motor block).
• Control algorithms are not assigned to the individual components, such as the battery
controller to the battery block. Instead the control algorithms are summarized in one
single control block, which embeds the controls for all components. Embedding the
controls of all components in one block makes rapid prototyping as one measure of
continuous validation impossible10. However Ricardo claims that the recent versions
are supporting rapid prototyping.
• The levels of information flow and physical component interaction are not separated.
9 A version including fuel cell vehicle models was not available
10 This is true for the 1996 version of HYZEM. However for recent versions of HYZEM Ricardo
Consultants claim the possibility of rapid prototyping. Because neither the software itself nor any detailed
information has been made available the statements could not be verified.
17
Figure 2- 2: Hyzem vehicle model ( most upper level of a series hybrid electric vehicle)
vehicle
vehicle
traman
traman
motblack
motblack
loaaux
loaaux
genblack
genblack
engdiet
engdiet
battery
Sum battery
consh
SH
Controller
Notes
Driver & cycle
18
2.2.2. The PNGVSAT ( Program for New Generation Vehicles Systems Analysis
Toolkit) Model
The program PNGVSAT or PSAT has been originally developed by the
Southwest Research Institute. Since August 2000 Argonne National Research
Laboratories is responsible for program maintenance and further development. Since
November 2000 PSAT 4.0 is available for registered researchers in the field of hybrid
and electric vehicles ( Rousseau 2000).
Figure 2- 3 shows the most upper level of the model of an indirect methanol fuel
cell vehicle with additional battery storage.
The existence of a driver model ( the icon showing the steering wheel in Figure
2- 3) indicates a causal, forward looking, modeling approach. The program documentation
confirms the separation of driver and vehicle and the forward- looking modeling approach
( Argonne National Laboratories 2000).
The general structure is similar to the model developed by Ricardo Consultants.
Specific similarities are:
• A driver controls the velocity of the vehicle,
• One single controls block organizes the component interaction ( Controller),
• Each individual component block employs three inputs and three outputs, which
could be interpreted identical to the inputs and outputs defined by Ricardo
Consultants. However the labeling in PSAT is different and orientated to the
physical value each port carries, e. g. the current going into the battery is labeled
“ current in”, the resulting voltage at the battery terminals is labeled “ voltage out”.
• Inputs and outputs of each block can be vectorized..
19
Despite these similarities PSAT employs more blocks than Hyzem. While Hyzem
employs only one block modeling the drive train between motor shaft and wheels PSAT
uses four blocks for the same task. PSAT models this part of the drive train with much
higher accuracy than all other models compared in this dissertation work. One example is
tire slip including modeling weight transfer, a feature important for modeling vehicles
that exhibit a high power – weight ratio, such as the EV1.
The incorporation of advanced modeling techniques, such as co- simulation is
possible ( though not realized) in version 4.0.
Although PSAT follows the general setup of Hyzem it does not strictly separate
component models from control algorithms. Because of this PSAT 4 does not qualify for
the employment of rapid prototyping. The fast and mutual validation of the program in
parallel to the development process of a physical vehicle employing rapid prototyping is
not possible. Another consequence of the mix of control algorithm with component
models is that a validation on the component level is not possible. One example for this is
the validation of the stand- alone battery model. The battery model includes current
limitations that are not part of the physical battery but realized in the motor controller
software and power electronics. The effect is that even a short circuit of the battery model
would not result in a voltage drop to zero volts and a current that exceeds the operational
limits. In other words a largely oversized motor would still work fine with the battery
without noticing that it draws a power much beyond what the battery is able to deliver. In
fairness, is has to be said that PSAT as a complete model does not calculate anything
wrong. However the result of the merge of a battery model with motor controller
20
characteristics is a difficult to oversee structure that makes changes and program
maintenance time consuming.
A helpful feature of PSAT is the graphical user interface ( Figure 2- 4). This
graphical user interface is very similar in appearance and logic to the one used in Advisor
3.0. It supports the following functions:
• Choice of vehicle topology ( series, hybrid, conventional, split),
• Choice of vehicle and component data,
• Component choice ( a list of predefined components is available),
• Component scaling ( battery, fuel cell system and electric motor),
• Choice of control strategies,
• Choice of drive cycle,
• Parametric studies,
• Display of results ( traces of values),
• Summery of results.
However the graphical user interface did not work in all cases and was therefore
only of limited use. Also the use of a graphical user interface limits the flexibility of the
program.
A fuel cell system model is provided. It has the following characteristics:
• The model covers warm up times and penalties associated with the warm up of
the system.
• Emissions are considered in the model but currently all data for modeling
emissions are set to zero.
21
• Transient characteristics of the reformer are modeled with a first order transfer
function. The stack characteristics are modeled using a one- dimensional steady
state lookup- table.
• The airside and water and thermal management characteristics are only
considered through their impact on the overall fuel efficiency and transient effects
are not taken into account.
• In summery it could be said PSAT provides a fuel cell system placeholder model
that mimics the effects of a fuel cell system - instead of a model based on
fundamental principles.
Strengths of PSAT are:
• Availability of a large variety of vehicle concepts
• Graphical user interface
Weaknesses of PSAT are:
• the merge of controls and component models, together with the not strict
separation of functionality hurts rapid prototyping as one method of continuous
validation
• the merge of controls and component models does not allow validation on the
component level
• the merge of controls and component models lead to difficult to oversee interfaces
and potentially problems in program maintenance and modifications
22
• The documentation references mostly to the graphical user interface. However
many parts in the actual program are not explained11.
11 At the time of this dissertation the documentation was not finished yet.
24
workspace
sum1 wh_ v01 veh_ v01
ptc_ series_ fc_ pos1_ au_ v01
mc_ v01
Disclosure
main_ disclosure
fd_ v01
fc_ v03
ess_ v01
drv_ v02
curves plot
cpl_ v03
clock
accelec_ v01 au_ v01
t_ hist
info_ tx info_ wh info_ veh
info_ ptc
info_ mc info_ fd
info_ fc
info_ ess
info_ drv
info_ accelec info_ cpl
0
Figure 2- 3: PSAT model ( most upper level) for the example of an indirect methanol fuel cell hybrid vehicle.
25
Figure 2- 4: Graphical user interface PSAT.
26
2.2.3. The Advisor ( Advanced Vehicle Simulator) Model
Advisor has been programmed by National Renewable Research Laboratory
( NREL) and is, after registration, freely available on the Internet ( National Renewable
Research Laboratory, 2000). Figure 2- 5 shows the most upper level of the Simulink code
for the case of an indirect methanol fuel cell vehicle.
The program is setup in a backwards approach, e. g. the model is not causal.
However according to the Advisor online documentation Advisor labels itself as a hybrid
backwards/ forwards approach. This name is confusing because it does not recognize the
inherent non- causality within the structure of the program, the key element of a
backwards- facing model as defined by Ricardo Consultants ( Heath, 1996), Southwest
Research Institute ( Mc Broom, 1999) and Bengt Jacobson ( Jacobson, 1995) 12. As a
consequence of the reverse causality the model is considered to be less physical and less
mathematically sound. 13
Advisor is programmed in Matlab/ Simulink. However for special modeling
aspects the program has been linked to several program tools. John A. MacBain provides
in his paper “ Co- Simulation of Advisor and Saber- A Solution for Total Vehicle Energy
Management Simulation” one example for co- simulation of Advisor and Saber
( MacBain, 2000). However due to the reverse causality the employment of this method is
limited. Furthermore MacBain describes the application of co- simulation as the only
solution for simulating the closely coupled mechanical and electrical systems in series
hybrid vehicles. This is not true. The UC Davis hydrogen model allows the simulation of
12 Bengt Jacobson did not use the terms forward and backward looking models. Instead he used the terms
driver controlled for the causal model and conventional model for the “ unnatural causality”. Important is
that causality was his reason to distinguish both approaches.
27
this vehicle type without employing the method of co- simulation ( UC- Davis, Fuel Cell
Modeling Team, 1998). This fundamental misjudgment can be taken as one indicator
how confusing the reverse causality of Advisor and other backwards- looking programs
could be to users.
From a practical point of view the reverse causality is one major obstacle that has
been already pointed out14. The program compensates this partly with an extensive
graphical user interface and a large component library. Because of these features the
standard user is not required to look into the details of the model. The good online
documentation also provides good support in application questions. However, whenever
the model itself needs to be modified the user is required to follow the logic dictated by
the reverse causality. This could become more challenging than the physical issues
involved with the desired modification. Because of this the model is considered neither
flexible nor transparent compared with forward- looking models.
The reverse causality makes the use of control algorithms for rapid prototyping
approaches impossible. Therefore this method of mutual validation of the model is not
available to the user.
13 See appendix.
14 See appendix.
28
Figure 2- 5: Advisor model of an indirect methanol hybrid fuel cell vehicle
wheel and
axle < wh>
vehicle < veh>
gal
total fuel used
( gal)
power
bus < pb>
motor/
controller < mc>
gearbox < gb>
fuel cell
control stategy
< cs>
fuel
converter
< fc> for fuelcell
final drive < fd>
exhaust sys
< ex>
energy
storage < ess>
drive cycle
< cyc>
fc_ emis
ex_ calc
t
To Workspace
Version &
Copyright
AND
emis
HC, CO,
NOx, PM ( g/ s)
Clock
29
Figure 2- 6: Graphical User Interface ( GUI) of Advisor 3.0
0.15 0.15
0.2
0.25 0.25
0.3 0.25
30
According to the online documentation, Advisor provides direct- hydrogen, direct-methanol
and indirect- hydrocarbon fuel cell vehicle models. In the current version an
indirect- methanol system is not available ( August 2000, 3.0).
The dynamic interaction among components, such as feedback effects, is limited.
Subcomponents of the fuel cell system, such as the fuel reformer, air supply or water and
thermal management are only modeled in terms of their impact on the net fuel cell system
efficiency. Dynamic effects within the fuel cell system itself, such as reformer and air
supply time lags, are not considered. For the case of the indirect- hydrocarbon system
emissions, are not predicted.
Strengths:
• The strength of advisor is the detailed graphical user interface ( Figure 2- 6) that
allows the setup and analysis of a wide range of vehicle configurations. The user
can choose between 9 predefined drive train configurations. Each configuration
allows the choice between 19 electric motors, 9 batteries and 7 fuel cell systems
( Wipke, 1999 and National Renewable Energy Laboratories, 2000). The
mentioned components are scaleable and could be combined in a vehicle. The
user interface is intuitive and provides rapid access for the educated user to the
capabilities of the model.
• Short runtime. Because Advisor is a backwards looking model it runs between 2.6
and 8.0 times faster in standard drive cycles than forward looking models ( Wipke,
1999).
Weaknesses:
31
• Documentation helps only very little if the model needs to be modified.
• The reverse causality makes it difficult to follow the logic of the model. This is
one major obstacle for future improvement and development.
• Interaction between fuel cell stack, fuel processor and drive train does not include
feedback effects. For example it is assumed that the fuel processor is always able
to deliver the by the stack required reformate in time. The effect of a drop in stack
voltage because of a supply shortage of reformate gas is not modeled, and
consequently the electric motor would not provide less torque because of the
voltage drop. The feedback of the various components is essential for the
modeling of one major issue of fuel cell system and vehicle analysis - transient
behavior. The model allows one to investigate only in a very limited way the
impacts of different component configurations, parameter variations and control
strategies on transient behavior.
• If one component is not able to supply the value required by the previous stage,
the operating point of the requesting component is not corrected. If component
characteristics vary largely over the operating regime, then ignoring the change of
the operating point could impose a large error on the results. An iteration process
downstream of the limiting component could potentially solve this problem.
However this would significantly complicate the model and is not realized in the
current version of Advisor.
32
2.2.4. The UC- Davis Hydrogen ( 1998 Version) Model
The original direct hydrogen fuel cell vehicle model of University of California,
Davis ( UC- Davis) was programmed during 1998. It is part of a modeling effort sponsored
by a group of industry and public sponsors and is not publicly available. It is essentially
based on a previous version of Advisor and follows therefore the same structure of a
backwards- facing model ( Figure 2- 7). From a practical point of view the complications
are the same as with the Advisor model and are mainly a direct result of the reverse
causality. The program employs also an extensive graphical user interface easing the
simulation of the different vehicle configurations ( Figure 2- 8).
The model is specialized for direct hydrogen fuel cell vehicles in a load following
and load leveling configuration. In addition pure battery electric vehicles could be
modeled.
Similarly to Advisor, the fuel cell system is modeled in non- transient form
employing steady state polarity plots characterizing the fuel cell stack ( fuel cell system
place holder model).
In addition to the actual fuel cell model, algorithms have been developed that
optimize the interaction between various compressor technologies and the fuel cell stack.
The results of this optimization process are then included into the vehicle model.
However the combination of fuel cell stack and air supply with the optimization strategy
makes it difficult to gain the necessary input data in a laboratory for a specific stack or
compressor supplier.
A new forward- looking direct hydrogen fuel cell vehicle model has succeeded
this program in 2000.
33
Strengths:
• Short runtime similar to Advisor,
• Graphical user interface including features for the automatic report generation.
• Attempt for the integration of an optimal compressor operating strategy. The
direct hydrogen model of UC Davis is the only model ( discussed in this overview)
addressing and discussing the potential energy savings in this area.
Weaknesses ( see Advisor):
• Reverse causality makes it difficult to follow the logic of the model and is one
obstacle for further improvement and development,
• No feedback effects between motor and fuel cell system interaction modeled,
• No correction of the operating point if one component is unable to meet the
request,
• Separate program required for the integration of new fuel cell stacks and
compressors or the modification of the compressor control strategy (“ config”
model).
34
Figure 2- 7: UC Davis Hydrogen Fuel Cell Hybrid Vehicle Model
m/ sec
trip
trans-mission
stop
simulation
at specific
SOC
road
load
motor/
controller
energy
storage
clock
actual velocity mph
Simulation
Results
SOC last
Fuel Cell
System
35
Figure 2- 8: Graphical User Interface of the Hydrogen Fuel Cell Hybrid Vehicle Model of UC Davis
36
2.2.5. The Simplev ( Simple Electric Vehicle Simulation) Model
Idaho National Engineering and Environmental Laboratories ( INEEL) developed
Simplev beginning in 1990. Since then several updates have been released. The latest
update is Simplev 3.0. However the simulation package has been phased out in 1997.
It is programmed applying a backwards method ( Idaho National Engineering and
Environmental Laboratory, 1993). This programming approach is physically and
mathematically less solid than the forward- looking approach15.
Simplev does not support the method of co- simulation. Because Simplev is
programmed in Basic, and the source code had not been made available, it is not possible
for the user to expand and modify the initial program package.
Because of the reverse causality Simplev does not support rapid prototyping.
The required input data are standard vehicle and component parameter and steady
state maps for motor efficiency, transmission efficiency etc. All the input data are either
available or could be made available using standard methods, such as battery and motor
bench tests. The program assists the user with a simple graphical interface. The runtime is
very short compared with the other program packages.
Simplev is capable of simulating various types of internal combustion engine
hybrid and battery electric vehicles. Simplev, in its original form, is not able to simulate
fuel cell vehicle concepts.
It should be noticed that Simplev was introduced in 1990, and was among the first
comprehensive programs modeling vehicles employing electric drive trains. Simplev was
phased out by INEEL in 1997.
15 See appendix
37
Strengths:
• Runtime
Weaknesses:
• Backwards approach,
• No fuel cell vehicle modeling capabilities,
• The electric drive train is not sensitive to voltage,
• Not flexible ( Source code not available),
• No documentation for version 3.0,
• No longer available.
38
2.3. Summary
Several vehicle- modeling tools have been introduced and compared with each
other. The points of comparison have been a list of generic requirements for
mathematical modeling stated at the beginning of the chapter and restated in the first
seven items in Table 2- 5. These criteria define the theoretical potential of the modeling
approach. In addition in the second half of Table 2- 5 ( items 8- 10) the actual realized
potential has been compared among the different models. Finally the last row states the
public availability in October 2000.
The compared models could be classified in two different groups. Hyzem and
Psat as forward looking models and Advisor, UC- Davis H2 ( 1998 version) and Simplev
in the group of backwards looking models.
The items 1- 5 in Table 2- 5 state the theoretical potential of the models to
incorporate future developments in an efficient and time saving manner. It can be seen
that in this respect the group of causal forward- looking models offers a higher potential
than the group of non- causal backwards looking models.
The item Nr. 6 “ ease of use” includes two different aspects. First, the support the
user receives through a graphical user interface and a good documentation, and second,
the logical structure of the model and how it supports modifications. Table 2- 5 shows that
none of the models have an advantage regarding the ease of use. However this represents
only the current state. Hyzem is valued neutral because it does not support the user with a
graphical user interface but has a causal structure easing understanding and
modifications. Advisor, UC- Davis H2 ( 1998 version) and Simplev are valued neutral
because they employ a graphical user interface and a non- causal structure. Psat is valued
39
neutral although it offers a graphical user interface and a forward looking structure. The
reason is that version 4.0 was still in the development state and the user interface was
little flexible and unstable. Because a graphical user interface could easily be added to the
causal models, while changing the non- causal structure of the backwards- looking models
is not possible the theoretical potential for a better “ ease of use” for the causal models is
estimated to be higher.
The availability of input data ( item 7), though important, is not a feature that
distinguishes the models. Only the UC Davis Hydrogen model ( 1998 version) has a
( minor) disadvantage in this area because of the combination of stack and air compressor
data. 16
Items 8- 10 compare more specifically how much of the theoretical potential of
each model has actually been realized in the current versions. Again the models could be
separated into the causal and non- causal types.
Item 8 shows the vehicle concepts realized today. The differences shown should
not be over interpreted. In principle all vehicle types could be modeled with each model.
Most of the differences shown could be explained based on the history of the individual
models and their sources of funding, primary objective, etc. However the fact that
Advisor does not include an indirect methanol fuel cell vehicle model could be one hint
towards the difficulties of incorporating non- instantaneous responding systems, such as a
methanol steam reformer, into the model.
Item 9 compares the possibilities of incorporating dynamic characteristics in each
model, on hand of the example of start up issues and fuel processor time constants.
40
Though the incorporation of these features is in principle possible in all models, the
required effort for the case of non- causal models is much larger. Consequently none of
the mentioned features has been realized in this vehicle group. The causal models have a
significant advantage over the non- causal models. The reason is that the causal structure
allows the incorporation of dynamic characteristics without difficulties if the physics of
the system are understood.
Item 10, the issue of emissions, is not an area in which the models are
fundamentally different. All models are in principle able to model emissions. However
for models only considering hydrogen as a fuel ( UC- Davis, H2) the task of modeling
emissions is irrelevant. The applied method of modeling emissions in today’s program
versions is quasi- static with tables including the emissions depending on the emitters
( anode gas burner, fuel processor) operating point.
Finally item 10 compares the availability of the individual models in October
2000. At this time only Advisor was publicly available ( as free download on the Internet).
However the Southwest Research Institute and Argonne announced that the PSAT model
would be made available at a later time this year. Since October 2000 a beta version of
PSAT is already available for researchers in the field of fuel cell vehicle modeling only.
From a fundamental point of view none of the above models are satisfying. The
investigated models compromise in a number of different areas, such as separation of
control algorithms from component models and causality. As a result the models become
difficult to understand, non- modular ( even if they appear modular on the surface) and
difficult to validate.
16 This comparison only considers the vehicle level. However in addition to the UC Davis H2 vehicle
model a second model is existing generating the necessary vehicle model input data from standard data
41
Also, because of the number of compromises made, none of the investigated
models appears suitable as a teaching instrument in companies or universities. Although
this aspect is secondary for a professional use in industry, or in the policy arena, it seems
important that long- term suitable tools for teaching in the area of fuel cell vehicles are
available.
Based on this comparison a new fuel cell vehicle model is proposed. Key
characteristics of this new model are:
• Emphasis on fuel cell vehicles,
• Incorporation of hybrid concepts including ultra capacitors,
• Causal structure,
• Preparation of rapid prototyping,
• Incorporation of dynamics aspects,
• Modular topology,
• Incorporation of the new indirect methanol and indirect hydrocarbon fuel cell system
models of UC- Davis ( Eggert, 2000, Fuel Cell Modeling Group, 2000),
• Incorporation of the new direct hydrogen fuel cell system model ( Cunningham,
2000),
• Logical structure.
such as compressor maps and stack properties ( config model).
42
Model
Requirement
HY- ZEM PSAT Advisor UC- Davis
H2
Simplev
1. Theoretical
soundness
+ + - - -
2. Completeness + O O O O
3. Flexibility + O - - -
4. Expanded
resolution
through co-simulation
+ + O - -
5. Validation
supported
through rapid
prototyping
+ ( current
version)
- ( 1996
version)
- - - -
6. Ease of use O O O O O
7. Input Data
Available
+ + + - +
8. Realized fuel
cell vehicle
models ( 2000)
Indirect -
Methanol
and direct-
H2 in
hybrid and
non- hybrid
Versions,
no ultra
capacitor
designs
Only
battery
hybrid
fuel cell
Vehicles,
no ultra
capacitor
designs
Indirect-
Gasoline
and direct-
H2 in
hybrid and
non hybrid
versions,
no ultra
capacitor
designs
Direct- H2
in hybrid
and non -
hybrid
versions,
no ultra
capacitor
designs
-
9. Dynamic
Considerations
( Start up,
reformer time
constants)
+
current
version
-
Place
holder
model
-
Place
holder
model
-
Place
holder
model
-
10. Modeling of
Emissions
+ ( maps) +( maps) - Not
applicable
+ ( maps)
11. Availability
( October 2000)
- +( free17) + ( free) - -
Table 2- 5: Benchmark (- negative or not possible, O neutral, + good).
Not emphasized are:
17 For registered researchers.
43
• The employment of a graphical user interface,
• Large component libraries,
It is expected that through these key features a new fuel cell vehicle model could
be developed with applications in
• Academia and government ( in teaching and as a tool for policy analysis),
• The vehicle industry ( for the analysis of different concepts),
• The component industry ( for product planning and technology comparisons).
44
3. Applied Modeling Methodology
3.1. General Aspects
For a realistic and defendable vehicle model, only a physically and
mathematically well- defined and documented modeling approach is acceptable.
Therefore this dissertation work chose a causal forward looking18 modeling approach.
For modeling of the control algorithms, an approach emphasizing the strict
distinction between the controlled system and the controller controlling the system is
proposed.
For the modeling of the components, either an approach based on first principles
or an approach based on experimental data has been applied. Examples for the first
principle approach are the modeling of the mechanical properties of the vehicle ( inertia,
friction, rotational inertia) or the modeling of the fuel cell stack. Examples for modeling
based on experimental data are the use of efficiency maps for the electric motor and
transmission.
The decision of which approach to follow depends on:
• The availability of experimental data;
• The complexity a first principle component model would add to the overall model
and the effects on run time ( practicality);
• The purpose of the model, e. g. what is the question asked. If the emphasis is
towards aggregate vehicle properties, individual component models could
eventually be simplified. If the emphasis is on one specific component, modeling
18 See literature review ( Hauer 2000).
45
in greater detail than in the first case might be necessary. Two methods to
accomplish this are possible: First, by programming a more complex SIMULINK
model, and second by employing a special programming tool for a specific
component or characteristic. SIMULINK and the other, specialized, program, e. g.
SABER for electric components, would then work together. This method is called
co- simulation. Although not applied in this work, the modular, forward- looking
structure of the model supports the method of co- simulation.
Because of the modular structure of the model, the modeling of each component
is not limited to either the choice of a first principle model or an approach based on
experimental data. Component models are exchangeable as long as the interfaces are
compatible. Therefore the results of a detailed component model could be compared with
a simpler one running both in the same overall vehicle model. If the differences between
both models are neglect able and the focus of interest is on the vehicle and not the
component itself one might decide to use the simpler component model for the benefit of
a faster runtime.
In addition to the above- mentioned method of co- simulation, the model structure
supports the use of rapid prototyping. In this context, rapid prototyping means the process
of developing control algorithms in the software model, which are later transferred into
existing hardware.
The model supports also the concept of “ hardware in the loop,” allowing the
replacement of component descriptions of the software model with hardware. From a
modeling point of view, “ rapid prototyping” and “ hardware in the loop,” techniques offer
the chance for faster model validation.
46
3.2. Mathematics
3.2.1. Introduction
The modeling, based on first principles, is done by applying a standard
input/ output approach as described by Leonhard ( Leonhard 1985) and Foellinger
( Foellinger 1985) for time invariant systems with one or multiple inputs x( t) and one or
multiple outputs y( t). Mathematical component and hardware descriptions are formulated
in the form of ordinary differential equations with the time t as the independent variable.
The system description could be given in the form of one or several ordinary differential
equations dy/ dt = f( t, x( t), y( t)) for the output function y( t) ( Figure 3- 1).
Figure 3- 1: Time invariant input output system for one input x( t) and one output y( t) and a 1st order
differential equation relating output and input function.
The input function x( t) could be of any form, including discontinuous functions,
e. g. a step function or a pulse. The only limitation is that x( t) has to be defined for the
complete time interval of interest [ 0, t].
The output function y( t) is calculated as a function of the input function x( t)
applying the system description dy/ dt = f( t, x( t), y( t)). For a physical system no
singularities are expected. Therefore y( t) is defined for the whole time interval [ 0, t].
The differential equations describing the system could be either of linear or non-linear
form. The equations describing the system are not limited to first order equations.
f( t, x( t), y( t))
dt
dy =
x( t) y( t)
47
A system description with higher order differential equations is possible. In case that the
component model requires a higher order differential equation, e. g. nth order, it can be
transformed into a first order system of n differential equations that could be solved
easily in SIMULINK ( Mathworks corporation, 2001). The general approach for the
transformation of an nth order equation is to substitute the higher order derivatives by
introducing new variables.
Equation 3- 1 shows a nth order differential equation with the input function x( t)
and the output function y( t).
x( t) system input
y( t) system output
independent time variable
:
( ) , ( ), ( ), ( ) ,..., ( ) , ( )
1
( 1)
2
( ) ( 2)
=
=
=
  

  

= −
−
−
−
t
where
dt
d y t
dt
d y t
dt
f t x t y t dy t
dt
d y t
n
n
n
n
n
n
Equation 3- 1
To solve Equation 3- 1 in SIMULINK, it has to be rewritten into a system of n 1st
order differential equations for the n unknown functions y( x, t), y1( x, t) .. yn- 1( x, t) ( Equation
3- 2).
48
dt
y t dy t
y t
dt
y t d
y t
dt
y t d
where
y t
dt
dy t
y t
dt
dy t
y t
dt
dy t
y t
dt
dy t
g t x t y t y t y t
dt
dy t
n
n
n
n
n
n
n
n
n
( ) ( )
...
( ) ( )
( ) ( )
:
( ) ( )
( )
( )
...
( )
( )
( )
( )
( ) ( , ( ), ( ), ( ),..., ( ))
1
2
2
2
1
1
1
1
2
1
2
3
1
2
1 2 1
1
=
=
=
=
=
=
=
=
−
−
−
−
−
−
−
−
−
Equation 3- 2
The resulting system in Equation 3- 2 can be directly programmed in SIMULINK.
Essentially SIMULINK provides the solution not only for the function of interest y( t) but
also for the first n- 1 derivatives of y, respectively y1 … yn- 1.
The algorithm to rewrite the n- th order differential equation does not require
linearity in the original equation. It can also applied if the original equation is of non-linear
form. The order of the system is also not a constraint, although physical systems
are seldom of a higher order than two.
If the system has more than one input x( t), all inputs have to be considered. The
first equation in Equation 3- 2 is then a function of all inputs x1, x2 … xm, if m is the
number of input variables.
49
If the system has more than one output function y( t), the above method can be
applied for each output function.
An example of a multi input/ output system is the air supply system in which
pressure and flow rate set points are input variables and the actual pressure and flow rates
in the stack form the output variables.
Start of the simulation ( Initial values):
For the numerical solution, initial conditions for the integration of the system
have to be considered. For a system of nth order, n initial conditions are required. Initial
conditions are the values of y1( t= 0),…, yn( t= 0). They are incorporated in the form of
initial values of the integrator blocks in the SIMULINK diagram.
The so- derived first order system of differential equations could then be solved in
SIMULINK. An example of a solution to a 2nd order system in SIMULINK with one
input and one output is provided at the end of the chapter.
Discontinuities:
A discontinuity in this context means that the derivative from the left side is
different from the derivative from the right side in ( at least) one point of a function. The
function is then discontinuous in this point. An example would be if there is a kink in the
function.
Discontinuities are common in the control algorithms applied for controlling the
various components. They are introduced in the form of saturation blocks, switches,
thresholds, and tables, and are necessary to model the applied control algorithm.
50
SIMULINK offers a vast number of functions to ease the incorporation of discontinuities
into the model.
In an analytical approach, the presence of discontinuities makes it harder to solve
the equation because it has to be solved for each continuous interval separately.
For the numerical approach applied in this work, the problem of discontinuities is
less challenging. The applied method for solving the system is to work with one set of
differential equations until the solution reaches a discontinuity. The simulation stops and
continues then with a new ( modified) set of equations, taking the old system’s last vector
of output values as vector for the initial values for the new system. After this, the
simulation proceeds as usual until the next discontinuity arises.
Not considered in this model are time discontinuities. Realistically, due to the fact
that most of the control algorithms are programmed in the software and run in discrete
time steps in microprocessors, all control algorithms have to be modeled in discrete form.
However, due to the high processor clock speed in comparison to the system time
constants, the impact of time discontinuities is minimal and could be neglected. If the
processor clock speed is in the order of magnitude of the inverse of the smallest time
constant within the controlled system model, the control algorithm would have to be
modeled in a time discrete form ( Leonhard 1990).
Applied solving algorithm for solving differential equations:
SIMULINK offers several solvers supporting the numerical integration of
ordinary differential equations.
The solvers provided could be classified as variable step solvers and fixed step
solvers.
51
Fixed step solvers do not vary the simulation step size during the simulation.
Therefore the step size has to be small enough to capture the most transient intervals of
the solution with sufficient enough accuracy. On the other hand, a too small step size
slows the simulation down. For the hybrid vehicles modeled in this work, the
recommended method is the Euler method ( ODE 1). The use of this algorithm for hybrid
cases shortens the execution time significantly. Alternative fixed step solvers, available in
SIMULINK, are listed in Table 3- 1.
Variable step solvers vary the step size depending on the slope of the solution. In
intervals with a small slope, the step size is increased, while in areas with steep slope
( rapid change of the solution), the step size is decreased to minimize the computational
error. The motivation of the variation in step size is to increase the speed of the
simulation. Variable solvers provided by SIMULINK are listed in Table 3- 1. Among the
variable step solvers the ODE 45 method provides a good compromise between reliability
( how likely is it that the simulation runs to the end) and efficiency ( how fast does the
simulation run) for the models discussed in this dissertation.
The standard solver applied in this work is the Euler algorithm ( Bronstein 1985)
for solving the system of differential equations that form the overall model.
Assuming the system that has to be solved is stated in explicit form ( Equation 3-
3) with the input function x( t) and the output function y( t) ( Figure 3- 1):
( ) f ( x( t), y( t))
dt
dy t = Equation 3- 3
Applying the standard differentiation formula leads to ( Equation 3- 4).
52
step size
:
( ) ( ) ( ) ( ( ), ( ))
Δ =
=
Δ
= + Δ −
t
where
f x t y t
t
y t t y t
dt
dy t
Equation 3- 4
Solving for y( t+ Δt) results in:
y( t + Δt) = y( t) + Δt ⋅ f ( x( t), y( t)) Equation 3- 5
The recursive algorithm in Equation 3- 5 is named the Euler formula. Starting with
an initial value y( t= 0), Equation 3- 5 allows the integration of the differential equation
stated in Equation 3- 3. The step size Δt stays constant in this algorithm. In some cases,
especially if the solution has large intervals [ t1, t2] with only little variation, the
adjustment of the step size could decrease the overall runtime. In intervals with little
variation, the step size is increased, while in areas with large variation ( or high dynamic),
the step size is decreased.
SIMULINK provides assistance for varying the step size offering variable time
step solvers. Essentially, the absolute tolerance ε between two steps and the relative
tolerance λ between two steps is calculated. If one or the other exceeds a ( in the user
interface adjustable) parameter, the iteration step is repeated with a smaller time step size
Δt ( Equation 3- 6). For checking the relative step size at locations y( t) close to zero a
special “ zero crossing feature” could be activated to avoid difficulties in determining the
step size in these situations ( Simulink 2001).
53
relative tolerance
absolute tolerance
:
( )
( ) ( ) or ( ) ( )
=
=
+ Δ − ≥ + Δ − ≥
λ
where
decrease Δt and repeat step
then
y t
if y t t y t y t t y t
ε
ε λ
Equation 3- 6
Table 3- 1: Fixed and variable time step solvers.
Fixed step size solvers Description
ode1
( Euler algorithm)
This method provides an efficient and reliable
solution for all hybrid cases. The recommended step
size is 0.005 sec. Recommended solver for all the
models used in this dissertation.
ode5, ode4, ode3, ode2 For a detailed description see the Simulink web page
( Simulink 2001). None of the listed solvers could
( significantly) increase the reliability or runtime of
the simulation.
Variable step size solvers
ode45 Based on an explicit Runge- Kutta ( 4,5) formula, in
general, ode45 is the best solver to apply as a " first
try" for most problems.
ode23, ode113, ode15s,
ode23s, ode23t, ode23tb
For a detailed description see the Simulink webpage
( Simulink 2001). Depending on the exact
configuration of the model one of the listed solvers
might lead to a ( i) more reliable, ( ii) more efficient
solution.
54
Runtime:
Two different effects determine the run time of the overall vehicle model:
• The complexity of the model ( this is the number of blocks forming the model);
• The system dynamics ( this is how fast the solution including intermediate values
change over time).
It appears obvious that the runtime increases with the system complexity. More
blocks add essentially more equations to the overall system and more equations means
that for every iteration step more computations have to be performed. For fixed
computational resources, the runtime increases with increasing complexity.
Not so obvious is that the system dynamics can have a much stronger effect on
runtime than the increase in complexity has. If a system is highly dynamic ( e. g. if parts of
the system are oscillating), in the interval of interest or shows rapid state changes only at
certain times the runtime could increase significantly. In either case the reason for the
increased runtime is that the simulation step size has to be small enough to capture all
transient effects. If the solution shows highly transient behavior only at certain points in
time ( e. g. during an acceleration), a variable step solver could reduce the runtime.
However, if the solution is transient over the complete interval of interest ( e. g.
oscillating), the step size has to be kept small all the time. For this case the number of
calculations and therefore the runtime increases independent from the choice of the
solver.
For the sake of a reasonable runtime and due to the finite computer power
( floating point operations / second), the modeling has be constraint to the dominant time
constants within the system.
55
A mixture of large and small time constants with a ratio of largest to smallest time
constant of several orders of magnitude slows the simulation significantly down. The
smallest time constant is effectively determining the step size and with this the total run
time of the simulation. For example, the consideration of the cable inductivity and
capacity between the fuel cell system and the electric drive train of a vehicle should be
avoided because this time constant is significantly smaller than the mechanical time
constants due to rotational inertia of the electric drive train or the vehicle mass.
On the other hand, in feedback systems it can be necessary to consider even
secondary ( small) time constants to avoid algebraic loops in the modeling process. The
presence of algebraic loops in the simulation model can be interpreted as an indicator that
the analysis of the system is not detailed enough. A significant aspect of the system has
not been captured in the model. 19 In case of the presence of an algebraic loop how an
additional time constant could be introduced into the system must be carefully analyzed.
For the case that no algebraic loop is present, one must consider if the introduction of
additional ( smaller) time constants is necessary to describe the interesting properties of a
system or if this just leads to an increase in run time. However, in this model it appears
that considering the system determining time constants leads to a system model without
any algebraic loops, which captures all dominant effects.
19 This is true for physical systems. It can be said that in nature no algebraic loops exist ( no immediate
feedback from a system output to a system input).
56
3.2.2. Example and Transfer into SIMULINK
Equation 3- 7 describes the horizontal movement of a vehicle with the mass m
considering an aerodynamic drag, wheel inertia, tire friction, and an external acceleration
Force F ( Gillespie 1992).
( ) ( ) ( ) 0
2
( ) ( ) ( ) 1
2
2
2
2 2
2 1 2 3
2
 + Θ ⋅ − =

 

 + ⋅ ⋅ ⋅ ⋅ 

 

⋅ + + ⋅ + ⋅  F t
dt
d s t
dt r
cw A ds t
dt
ds t
dt
ds t
dt
m d s t μ μ μ ρ
Equation 3- 7
Following the conclusions of the previous chapter the above 2nd order nonlinear
differential equation can be rewritten into a system of two 1st order differential equations
by the method of substitution ( Equation 3- 8).
( )
( ) ( )
2 ( ) ( ) ( ) 0
( ) ( ) ( ) 1
2
2 2
1 2 3
v t
dt
ds t
F t
dt
dv t
r
v t v t cw A v t
dt
m dv t
=
⋅ + μ + μ ⋅ + μ ⋅ + ⋅ ⋅ ρ ⋅ ⋅ + Θ ⋅ − =
Equation 3- 8
Rearranging Equation 3- 8 results in:
[( ) ]
( ) ( )
2 ( )
( ) 1 ( ) ( ) 2 ( ) 1 2
1 2 3
2
v t
dt
ds t
F t v t v t cw A v t
dt m
dv t
r
=
⋅ − + ⋅ + ⋅ + ⋅ ⋅ ⋅ ⋅
+
= Θ μ μ μ ρ
Equation 3- 9
In Equation 3- 9 s( t) has the meaning of the distance traveled from t= 0 until t and
v( t) is the vehicle velocity at the time t. Because the system of differential equations has
two unknown functions v( t) and s( t), two initial conditions have to be considered. These
are the vehicle velocity at the beginning of the experiment ( or simulation) v( t= 0) = v0 and
57
the location of the vehicle at the beginning of the experiment s( t= 0)= s0. Equation 3- 9
can be seen as the description for an input / output system. System input is the
acceleration force F( t) and system outputs are the vehicle velocity v( t) and the vehicle
location s( t). Together with the above- mentioned starting conditions, the system can be
easily solved in SIMULINK for all input traces F( t). Figure 3- 2 shows the graphical
representation of the SIMULINK algorithm.
∫
2
1
r
m+ Θ
2 ⋅ cw ⋅ ρ ⋅ A
1
F( t)
∫
v( t)
s( t)
x2
x2
-
+
-
-
-
μ1
μ2
μ3
Figure 3- 2: Graphical representation of Equation 3- 9.
The initial conditions s( t= 0)= s0 and v( t= 0)= v0 are equivalent to the integrator
status at t= 0. Therefore the initial conditions can be directly programmed into the
SIMULINK representation.
58
4. Model Description
4.1. Modeling Structure and Goals
This chapter explains the setup of the fuel cell vehicle model. The model is
developed using a forward- looking approach ( Hauer 2000). The model description starts
with the most upper level, the vehicle. This level illustrates how the driver is interacting
with the vehicle and how the drive cycle is fed into the model. After the establishment of
this overall modeling frame, the models for all major components are explained in the
chapter “ Component models.” The component models interface with each other and
form, together with the vehicle properties, the overall vehicle model. One individual
component could also consist of several subcomponents. One important characteristic of
this model is that the component interfaces transfer only physical properties from one
component to the other components. The limitation to “ physical“ interfaces qualifies the
model for the use in rapid prototyping experiments. It also benefits the understanding and
eases maintenance and further development because the model could be more easily
associated with an image of the physical reality of the vehicle. Because of the strict
modularity, individual component models could be tested off- line or replaced with a
different model for the same component if the interfaces of the replacement model match
the interfaces of the model replaced.
Besides the component models, the control strategies for the interaction of the
individual components determine the overall vehicle characteristics. These control
strategies are also explained under the headline “ Component models.” An example for a
control strategy in a non- hybrid vehicle is the control algorithm for the fuel processor. An
example for a control strategy in a battery hybrid vehicle is the activation of the fuel cell
59
system depending on the motor power and/ or the state of charge of the battery and/ or
other parameters.
The modeling effort pursues two objectives:
First to estimate fuel consumption, energy flows and losses, and the vehicle
dynamics ( acceleration time and top speed) for different vehicle configurations
( parameters) and different vehicle types ( hybrid, non hybrid vehicles).
Second the safe and fast investigation and development of control strategies for
the exploration of theoretical limits and the use in existing hardware later.
60
4.2. Vehicle Model
The uppermost level of the fuel cell vehicle model consists of the main blocks
“ Specified Drive Cycle”, “ Driver” and “ Vehicle" ( Figure 4- 1).
Figure 4- 1: Uppermost level of the indirect methanol fuel cell vehicle model.
Driver Vehicle
Specified
Drive Cycle
Vehicle
velocity
Brake pedal position
Acceleration pedal position
61
4.2.1. Drive Cycles and Driver Model
This chapter discusses the drive cycles available in the model and the algorithm
that compares these drive cycles with the actual vehicle velocity and adjusts the
acceleration and brake pedal position.
The block “ Specified Drive Cycle” describes the demanded driving profile by
specifying the velocity over the time. Standard drive cycles available in this simulation
tool are the drive cycles listed in Table 4- 1.
Available Drive Cycles Length /
Time
Max. speed /
Avg. speed
Max. accel.
Avg. accel.
Federal Urban Driving Schedule ( FUDS) 7.45 mi /
1369 sec
56.7 mi/ h /
19.6 mi/ h
1.48 m/ sec2
0.34 m/ sec2
Federal Highway Cycle 10.26 mi /
765 sec
59.9 mi/ h /
49.2 mi/ h
1.43 m/ sec2
0.13 m/ sec2
US O6 Cycle 8.01 mi /
600 sec
80.3 mi/ h
48 mi/ h
3.75 m/ sec2
0.45 m/ sec2
ECE Cycle 0.62 mi /
195 sec
31.1 mi/ h
11.4 mi/ h
1.05 m/ sec2
0.43 m/ sec2
MVEG Cycle 6.79 /
1220 sec
74.6 mi/ h
20.03 mi/ h
1.05 m/ sec2
0.37 m/ sec2
EUDC 90 6.58 mi /
1220 sec
55.9 mi/ h
19.4 mi/ h
1.05 m/ sec2
0.39 m/ sec2
EUDC 120 4.32 mi /
400 sec
74.6 mi/ h
38.9 mi/ h
0.83 m/ sec2
0.26 m/ sec2
Japanese 10- 15 cycle 2.59 mi
660 sec
43.5 mi/ h
14.1 mi/ h
0.79 m/ sec2
0.39 m/ sec2
Table 4- 1: Available standard driving cycles with their main characteristics.
The block “ driver” represents the driver properties and driver characteristics. The
main task is the comparison of the velocity specified in the driving cycle with the actual
vehicle velocity. In case the actual vehicle velocity is below the vehicle velocity specified
in the drive cycle the driver sends an acceleration command to the vehicle block. In case
the vehicle velocity is above the specified velocity the driver sends a brake command to
62
the vehicle block. In a real vehicle, the acceleration signal and the brake signal represent
the position of the acceleration pedal and brake pedal. From a systems point of view the
driver can be seen as a controller for the “ system” vehicle. The inputs for the “ system”
vehicle are the acceleration and brake commands and the system output is the vehicle
velocity. Although the presence of a driver model is important for the setup of the
simulation, this analysis will not focus on the block " driver." The only criteria this block
has to meet is to ensure that the vehicle follows the drive cycle as closely as possible
whenever physically possible. In this respect the block " driver" has the same task as a
driver on an emissions bench, namely following a given drive cycle.
The complete driver model is shown in Figure 4- 2.
Drive cycle
Td
-
+
Ti
-
+
Tr
>= 0
<= 0
proportional
integral
predicting
the future
delay
vehicle velocity
k1
k3
1/ Ti
+
+
+
reaction
time
acceleration
request
brake
request
y1
y2
y3
y4
Figure 4- 2: Driver model.
The model inputs are the specified drive cycle and the vehicle velocity. The
model outputs are the normalized ( between 0 and 1) acceleration request and the
normalized ( between 0 and – 1) brake request.
The following steps are taken to calculate the output values in dependence of the
input values. The ( actual) vehicle velocity is subtracted from the ( delayed) drive cycle
63
request. The difference between both values is fed into a proportional integral controller
( PI controller). The proportional part is calculated according to Equation 4- 1.
( )
time [ sec]
time is the time the driver looks into the future [ sec]
drive cycle velocity [ km/ h]
vehicle velocity [ km/ h]
proportion al factor of the PI algorithm [ 1/ km h ]
:
y ( ) ( ) ( )
- 1
1
1 1
=
=
=
=
= ⋅
= ⋅ − −
t
T
v ( t)
v( t)
k
where
t k v t v t T
d
cycle
cycle d
Equation 4- 1
The integral part of this PI controller is realized using an integral algorithm with a
build- in anti- windup feature ( Figure 4- 3). The reason is to avoid the windup of the
integrator to very high values in cases the vehicle is physically not able to meet the drive
cycle, e. g. in an acceleration experiment). Equation 4- 2 describes the algorithm of the
integrator with anti- windup function.
y ( ) output of the integrator with anti - windup [ 1]
y ( ) intermediate value [ 1]
c feedback constant [ km/ h]
integration constant [ h/ km]
:
( ) 1 ( ) ( ) ( ( ))
2
2
1
0
2 1 2 2
=
′ =
=
=
⋅   
  
′ = ⋅ − − + ⋅ − ′ ∫
t
t
T
where
v t v t T c y y t dt
T
y t
i
t
cycle d
i
Equation 4- 2
The final output of the integrator with anti- windup is stated in Equation 4- 3.
upper and lower bound for y [ 1]
:
( ) if ( )
( ) ( ) if ( )
2 2
2 2 2 2
2 2 2 2
=
= ′ ≥
= ′ ′ <
y
where
y t y y t y
y t y t y t y
Equation 4- 3
64
Ti
++
- +
input
ideal
integrator limiter
c1
y2’ y2
Figure 4- 3: Integrator with “ anti- windup function”.
In addition to the PI algorithm, a third component impacting the driver request
can be added ( Equation 4- 4). This third component takes into account that on an actual
roller test stand the driver is able to foresee the future drive cycle. 20 This knowledge
about the future can improve the driver’s decision and allows a more accurate following
of the drive cycle. The value the driver pays to the future is taken into account by a gain
block. A gain of zero would mean that the driver does not pay any attention to the future
at all. With increasing gain his attention increases. The delay determines how far the
driver looks into the future. A delay of zero would be equivalent to a time horizon of zero
seconds. If the delay time increases, the driver’s time horizon increases.
20 In a roller test stand the drive cycle request is communicated on a screen. This screen does not only show
the current velocity request in digital form. Instead, the drive cycle, including the next few seconds of the
drive cycle together with the actual vehicle speed, is displayed in the form of speed traces. Therefore, the
driver is able to take the future velocity requests into account and base his current decisions on this
additional knowledge. The net effect is that the driver can follow the drive cycle more accurately.
65
( )
( ) intermediate value [ 1]
constant for how the driver values the future [ h/ km]
:
( ) ( ) ( )
3
3
3 3
=
=
= ⋅ − −
y t
k
where
y t k v t v t T cycle cycle d
Equation 4- 4
All three intermediate values y1, y2, and y3 are summed and filtered through a low
pass filter in the form of a first- order transfer function ( Equation 4- 5).
y ( ) intermediate value [ 1]
filter time constant [ sec]
:
( ) ( ) ( ) ( )
( )
4
4 1 2 3
4
=
=
⋅ + = + +
t
T
where
y t y t y t y t
dt
T dy t
r
r
Equation 4- 5
Finally, the filtered value is limited to values between - 1 and 1, which are then
interpreted as the driver’s request for more or less acceleration. According to Equation 4-
6, positive values are interpreted as a request for acceleration. Negative values are
interpreted as a request for deceleration ( braking).
brake_ request driver request for deceleration ( braking) [ 1]
acc_ request driver request for acceleration [ 1]
where :
0 if y ( t) 0
1 if y ( t) - 1
if - 1 y ( t) 0
0 if y ( t) 0
1 if y ( t) 1
if 0 y ( t) 1
4
4
4 4
4
4
4 4
=
=
= >
= − <
= ≤ ≤
= <
= >
= ≤ ≤
brake_ request
brake_ request
brake_ request y ( t)
acc_ request
acc_ request
acc_ request y ( t)
Equation 4- 6
66
4.2.2. Physical Vehicle Model
In the previous chapter, the driver model and how the driver controls the actual
vehicle velocity were discussed. In this chapter, the model for the vehicle and its main
components and component arrangements will be explained. The block “ vehicle” in
Figure 4- 4 contains the four sub- blocks “ Drive Train,” “ Vehicle Curb,” “ Power Source,”
and “ Vehicle Controls” ( Figure 4- 4).
The inputs of this block are the brake pedal position and the acceleration pedal
position. Both are derived in the previous chapter. The model output is the actual vehicle
velocity. The acceleration pedal position feeds into the block " Drive Train" and
determines the fraction of the maximum motor torque available supplied to the vehicle
wheels. The brake pedal position feeds into the block “ Vehicle Controls.” This block
separates regenerative braking ( in hybrid vehicles only) and mechanical braking. The
request for regenerative braking is fed to the block “ Electric Motor” and the request for
mechanical braking is fed directly to the block “ Vehicle Curb.”
Drive
Train
Vehicle
Curb
Power
Source
current
torque
motor speed
voltage
acc.
pedal
position
brake pedal
position Vehicle
Controls
velocity
Figure 4- 4: Content of the block " Vehicle".
67
The block “ Drive Train” includes models for the power electronics for the electric
motor, the electric motor itself, controls for the electric motor, and the transmission.
Depending on the driver request, expressed by the acceleration pedal position and brake
pedal position, the block “ Drive Train” provides torque to the wheels and draws current
from the power source ( battery, ultra capacitor, or fuel cell stack).
The block “ Vehicle Curb” models the mechanical properties of the vehicle curb
such as aerodynamic drag, rolling resistance, mass, etc.. The inputs into this block are the
applied wheel torque and the signal for the mechanical brake fraction. The outputs are the
vehicle velocity and the motor speed. In designs not considering tire slip and a one- speed
transmission, both values are directly correlated with each other.
The block “ Power Source” could include models for a fuel cell system, a battery
system, an ultra capacitor system, or a combination of all three systems. The input of this
block is the electric current drawn by the motor. The output is the voltage seen by the dc
terminals of the power electronics for the electric motor. For the case of a non- hybrid fuel
cell vehicle this is the same voltage as the fuel cell stack voltage. In hybrid designs, this
voltage could be the battery voltage or any other voltage depending on the exact design.
The overall design of the vehicle model incorporates two major feedback loops
motivated by the dependence of the maximum motor torque of the electric drive train on
the voltage supply and the motor speed. As soon as the driver signals a torque request the
electric drive train starts providing torque to the wheels. Because of this torque supply,
the vehicle accelerates and the motor speed increases. This increase in motor speed feeds
back to the block “ Drive Train” because of the sensitivity of the motor torque to
68
fluctuations of motor speed. This feedback loop represents the feedback on the
mechanical side of the vehicle.
As soon as the motor starts spinning, it provides mechanical power to the wheels.
It can only do this by drawing electrical power from the block “ Power Source.” As a
result, the motor draws an electric current from the power source. Due to the internal
resistance21 of the power source, the voltage at the motor terminals drops depending on
the load current drawn. Because of the sensitivity of the maximum motor torque on the
supply voltage, the drop in voltage feeds back to the electric drive train. This feedback
loop represents the feedback effects on the electrical side. Mechanical and electrical
feedback together determine the overall characteristics of the combined system drive
train, power source, and vehicle curb, which form the overall vehicle model.
This setup of the vehicle is close to the setup of a physical vehicle. The only
interface22 between the drive train and the source of electric power is the electric
connection between both components. This interface can be fully described by change of
voltage and current over time. On the mechanical side, the interfacing variables between
the drive train and the vehicle curb are the wheel torque and the wheel speed. Similar to
the electric side, the interface can be fully described by providing both values in time.
Properties of the vehicle and the vehicle environment
The overall vehicle is modeled according to the force balance stated in Equation
4- 7. This equation accounts for the aerodynamic drag force; the friction force due to the
rolling resistance of the tires; the vehicle inertia including rotational inertia of tires,
motor, and transmission; and the climbing force necessary to climb a hill. The sum of all
21 The internal resistance could vary over time.
69
these forces is the force required to operate the vehicle (“ motor” force and friction brake
force).
motor brake friction drag inertia c b F F F F F F lim + = + + + Equation 4- 7
The individual forces can be expressed according to Equation 4- 8 to Equation 4-
13. Solving Equation 4- 7 to 4- 13 for the vehicle velocity and then integrating yields an
equation for the vehicle velocity v.
The force necessary to accelerate or decelerate the vehicle is the force applied to
the vehicle by the electric motor plus the braking force due to the mechanical brakes of
the vehicle ( left side of Equation 4- 7). The applied motor torque is converted to a linear
acceleration force accessing the vehicle. The same has been done for the brake force;
although in reality this brake force is applied to the wheels, the model assumes a linear
braking force that decelerates the vehicle directly ( Equation 4- 8).
Maximum braking force [ N]
Driver request for braking [ 1]
Wheel torque introduced by the motor [ Nm]
Wheel radius [ m]
Force induced by the friction brakes [ N]
Force induced by the electric motor [ N]
:
max
max
=
=
=
=
=
=
+ = + ⋅
brake
wheel
wheel
brake
motor
brake
wheel
wheel
motor brake
F
q
T
r
F
F
where
q F
r
F F T
Equation 4- 8
The friction term represents the friction due to tire resistance and friction in the
wheel bearings ( Equation 4- 9).
22 Except information flow.
70
vehicle velocity [ m/ sec]
friction coefficient increasing with the square of the velocity [ m sec ]
friction coefficient increasing linear with velocity [ m sec]
friction coefficient independant of velocity [ 1]
gravity [ m sec ]
vehicle mass [ kg]
:
( )
- 2 2
2
- 1
1
- 2
2
1 2
=
= ⋅
= ⋅
=
= ⋅
=
= ⋅ ⋅ + ⋅ + ⋅
v
g
m
where
F m g v v friction
μ
μ
μ
μ μ μ
Equation 4- 9
The aerodynamic drag is considered according to Equation 4- 10.
frontal area[ m ]
coefficient of drag [ 1]
density of air [ kg m ]
:
2
1
2
- 3
2
=
=
= ⋅
= ⋅ ⋅ ⋅ ⋅
A
c
where
F c A v
w
drag w
ρ
ρ
Equation 4- 10
The force necessary to overcome the vehicle inertia is the sum of the force
necessary for accelerating the vehicle mass plus the force necessary for the acceleration
of the rotational inertia of the wheels.
Wheel speed in [ rad/ sec]
Wheel inertia [ kg m ]
:
2
=
Θ = ⋅
⋅
Θ
= ⋅ +
wheel
wheel
wheel
wheel
wheel
inertia
where
dt
d
dt r
F m dv
ω
ω
Equation 4- 11
The wheel speed and the vehicle velocity are related to each other according to
Equation 4- 12. This equation assumes that the tires won't slip. In case of tire slip, this
Equation has to be modified.
wheel
wheel r
ω = v Equation 4- 12
71
Finally, the climbing resistance ( the force required to go uphill or the force gained
going downhill) is considered in this model.
grade the vehicle needs to overcome [%]
:
sin tan 1 100
lim
=
  
  
  
  
= ⋅ ⋅ −
grade
where
F m g grade c b
Equation 4- 13
The sum of all forces impacting the vehicle determines, together with the vehicle
mass, the vehicle acceleration. Equations 4- 7 to 4- 13 are used to calculate the vehicle
acceleration as a function of time. The integration of the vehicle acceleration results in
the vehicle velocity. The required starting value at t= 0 sec represents the vehicle velocity
at t= 0 sec. This initial velocity is set to 0 km/ h. Equation 4- 14 shows the algorithm for the
calculation of the vehicle velocity. Figure 4- 5 is the graphical representation in form of a
Simulink diagram of this algorithm.
The vehicle velocity can be calculated for a given wheel torque. The wheel torque
itself depends on the vehicle velocity and is calculated in the block " motor." Because of
the non- linear relationship between the provided wheel torque and the vehicle velocity,
Equation 3- 14 cannot be solved explicitly. The braking force Fbrake_ max in Equation 4- 14
is less than or equal to zero.
72
q F m g v v grade c A v dt
r
T
r
m
v t
t
t
brake w
wheel
wheel
wheel
wheel
⋅  


 


⋅ ⋅ ⋅ ⋅ −   

  

  

  

 
  
⋅ + ⋅ − ⋅ ⋅ + ⋅ + ⋅ + 
 
  
 + Θ
=
∫=
−
0
2 1 2
_ max 1 2
2
2
1
100
sin tan
( ) 1
μ μ μ ρ
Equation 4- 14
2
velocity km/ h
1
wheel speed
rad/ sec
- K-wheel
radius - K-wheel
inertia
- K-velocity
m/ sec in
wheel speed [ rad/ sec]
3.6
velocity from m/ sec
to km/ h
velocity friction force in N
friction force1
v elocity f orce in N
climbing force
force in
velocity
force out
avoid
negative
velocity
v elocity drag f orce in N
aero drag
Sum
resulting wheel torque [ Nm]
mechanical brake f orce
resulting acc. f orce [ N]
wheel speed
velocity
Results
1/ s
Integrator
2
wheel torque
Nm
1
braking
force N
Figure 4- 5: Simulink representation of the mechanical vehicle properties.
73
4.3. Component Models
4.3.1. Electric Motor Including Power Electronic
Many different motor technologies for electric vehicle drive trains are in use
today. Among them are induction motors, permanent magnet brushless dc motors, dc-current
motors, and switched reluctance motors ( Nahmer 1996, Skudelny 1993).
Two different modeling philosophies are applied in today’s vehicle models for the
modeling of the electric drive train and the power electronics.
The first approach is based on fundamental physical principles. Motor torque and
speed are calculated based on armature current and field current ( armature current and
magnetic field for permanent magnet motors). This approach requires a detailed motor
model for each motor technology. A motor model for an induction motor would be
fundamentally different from a motor model for a brushless dc motor. The input
parameters for this approach are the motor geometry, material parameters, and the
electrical parameters of the motor coil and power electronics. Li and Mellor ( Li and
Mellor 1999) describe such a modeling approach for the case of a brushless dc motor. 23
The other possible modeling approach is based on static maps for the drive train
efficiency in dependence of the motor torque and speed and the maximum motor torque
in dependence of the speed and applied voltage. This second approach is followed by
Ricardo Consultants ( Heath 1996) and National Renewable Energy Laboratories ( NREL,
1999). This modeling approach is technology independent, e. g. the same model could be
used for different motor technologies. Only the motor describing parameters, such as
maximum motor torque and maximum motor speed and the above- mentioned maps have
23 In the paper, the brushless dc motor is referenced as a brushless ac motor .
74
to be adjusted for each specific motor technology and motor configuration ( size,
characteristic). The necessary input data for this approach could be gained on a motor test
stand similar to the one described by Nahmer ( Nahmer 1996). For gaining the efficiency
map, the motor is operated at one specific operating point ( torque and speed) and the
electrical input power is measured. The efficiency is the ratio of mechanical output power
over electrical input power. For gaining the map of maximum torque in dependence of
speed and voltage, the motor is operated at one operating point ( speed, voltage) and the
maximum motor torque the motor is able to deliver is measured ( increase of the
mechanical load until the motor speed drops while holding the terminal voltage constant).
Due to the significantly shorter runtime and better availability of the necessary
input data, the second modeling approach with static maps has been chosen in this
dissertation. For modeling of the motor transient characteristics, the static approach has
been modified and incorporates the mechanical time constant implied by the motor
inertia. This time constant is the dominant time constant and exceeds the electrical time
constant due to the coil inductivity and resistance, by far which is on the order of
microseconds ( Nahmer 1996).
The modeling based on static maps allows also the incorporation of all currently
applied motor technologies without changing the model structure.
Interface:
On the electrical side the motor model including power electronics interfaces with
the dc power source ( battery system, fuel cell stack, or ultra capacitor system). The
variables at this interface are the dc current and the dc voltage. On the mechanical side
the motor shaft interfaces with the transmission. Interfacing variables are the shaft torque
75
and the shaft speed ( Figure 4- 6). On the information side ( data bus) the motor receives
the brake pedal position ( only for hybrid vehicle designs with electrical energy storage)
and the acceleration pedal position. However, if the motor controller is excluded from the
actual motor, as shown in Figure 4- 6, the motor receives a signal for the requested motor
torque from the motor control algorithm.
brake
pedal
position
acc.
pedal
position
dc bus
voltage
motor
speed -
+
xx//
efficiency map
maximum
motor torque
dc- drive train
current
net
motor torque
motor control
algorithm
inner torque
motor η
dt
Θ⋅ dω
Figure 4- 6: Structure of the motor block including power electronics and motor control algorithms.
The characteristics of the motor and the power electronics are inside the by the dashed line marked
area. Outside of this area is the motor control algorithm that takes the inputs shown and derives a
signal for the requested motor torque.
Parameters:
For steady state operation, the motor including the power electronics is modeled
with a two- dimensional efficiency map ( Figure 4- 7). This map shows the overall motor
and drive train efficiency as a function of motor speed and motor torque for steady state
conditions. The influence of voltage fluctuation on the peak efficiency and shape of the
islands of constant efficiency is minor and can be neglected ( Nahmer 1996). However, if
76
the motor is operated at lower voltages, not all operating points shown on the map are
valid operating points. With decreasing voltage, the operating regime shrinks to the area
within the lines of maximum torque shown in the Figure 4- 8. Figure 4- 8 shows a map for
the maximum motor torque as a function of motor speed and terminal voltage. Both maps
are derived from experiments for the case of a 75 kW induction motor. The efficiency
map includes the power electronics. Therefore the maps represent not only the motor
properties but also the properties of the combined system of power- electronic and
electric- motor including control algorithm, such as torque limitation at lower voltages.
0 2000 4000 6000 8000 10000 12000
- 300
- 200
- 100
0
100
200
300
Motor speed [ rpm]
Motor torque [ Nm]
0.92
0.92
0.8
0.85
0.88
0.9
0.91
0.92
0.92 0.91 0.9
0.88
0.85
0.8
0.7
0.5
0.7
0.5
Motor Mode
Generator Mode
Figure 4- 7: Motor efficiency map.
77
0 1000 - 300 2000 3000 4000 5000 6000 7000 8000 9000 10000
- 200
- 100
0
100
200
300
200 V
400 V
250 V 300 V 350 V
200 V
250 V 300 V
350 V
400 V
Motor Mode
Generator Mode
Motor torque [ Nm]
Motor speed [ rpm]
3000 Figure 4- 8: Map of maximum torque.
Besides the maps shown in Figure 4- 7 and Figure 4- 8, the only other parameters
that characterize the electric motor including the power electronics are the rotational
motor inertia and the motor mass. The motor inertia determines mechanical transients of
the motor, e. g. the motor acceleration if no mechanical load is applied, and the motor
mass influences the overall vehicle mass and with this the vehicle acceleration for a given
configuration.
Algorithms:
For modeling purposes only the upper half ( 1st and 2nd quadrant) of both maps has
been measured ( acceleration mode). The lower half ( regenerative braking) has been
derived by mirroring the upper half. Because of friction within the motor bearings and
frictional losses due to the aerodynamic drag ( rotor) this assumption is not 100% correct.
While in the acceleration mode the frictional losses reduce the available net motor shaft
78
torque, in the regenerative braking mode the frictional losses would provide additional
shaft torque ( Figure 4- 9 and Figure 4- 10). Only if the mechanical frictional losses could
be neglected would the mirroring technique provide exact results. However, if the motor
is not cooled by forced air through a fan sitting on the motor shaft, the frictional losses
are much smaller than the provided net power. For this case the mirroring technique is
justified and the maximum torque in the generator mode equals the maximum motor
torque for the same speed and terminal voltage.
electric
motor
electric
power
electrical
losses
mechanical losses
( friction in bearings
and aerodynamic drag)
net shaft
power
Figure 4- 9: Power flow and losses in acceleration mode.
79
electrical
losses
electric
motor
electric
power
mechanical losses
( friction in bearings
and aerodynamic drag)
net shaft
power
Figure 4- 10: Power flow and losses in regenerative braking mode.
The motor efficiency during acceleration phases is stated in Equation 4- 15.
electrical power ( dc)[ W]
accessable net mechanical power [ W]
motor efficiency in acceleration mode [ 1]
:
_
motor
_
motor
=
=
=
=
el
mech net
el
mech net
P
P
where
P
P
η
η
Equation 4- 15
During phases of regenerative braking the motor efficiency is stated in Equation 4- 16.
motor efficiency in regenerative brake mode [ 1]
:
regen
_
regen
=
=
η
η
where
P
P
mech net
el
Equation 4- 16
The discussion above assumed the steady state operation of the electric motor. For
the transient case, the motor inertia has to be considered ( Equation 4- 17). The usable
motor torque supplied to the transmission is the motor shaft torque generated by the
motor minus the product of motor inertia and angular shaft acceleration. During phases of
vehicle acceleration, the torque supplied to the wheels is reduced and less torque is
available for the acceleration of the vehicle. During phases of deceleration, the motor
80
inertia effectively acts as an energy storage that has to be discharged for the deceleration
of the vehicle. The stored energy has to be dissipated in the brake system or converted
into electrical energy if the vehicle concept allows for regenerative braking.
Motor shaft speed [ rad/ sec]
Motor shaft torque [ Nm]
Motor inertia [ kg m ]
Torque supplied to the transmission[ Nm]
:
2
=
=
Θ = ⋅
=
= − Θ ⋅
motor
motor
motor
trans
motor
trans motor motor
T
T
where
dt
T T d
ω
ω
Equation 4- 17
The torque supplied by the motor to the transmission depends on the request of
the motor control algorithm multiplied by the maximum torque the motor is able to
provide ( Figure 4- 8). It is stated in Equation 4- 18. The request of the motor control
algorithm is derived from the inputs to this algorithm such as driver request and torque
reduction due to high or to low voltage. The motor controller and the embedded control
algorithms are described in the next chapter.
Bus voltage [ V]
Torque request motor controller [ 1]
voltage and speed [ Nm]
( , ) Max. motor torque at this specific
:
( , )
_ max
_ max
=
=
=
= ⋅
dc
motor dc motor
motor motor dc motor
V
p
T V
where
T T V p
ω
ω
Equation 4- 18
On the electrical side of the motor, the dc motor current is derived by balancing
mechanical power at the motor shaft and electric power at the motor terminals. The motor
torque times the motor speed is equal to the product of drive train voltage times drive
81
train current times motor efficiency. Solving this power balance results in Equation 4- 19
for the drive train current on the dc- side of the power electronics if the motor is in
acceleration mode.
Motor efficiency [ 1]
Dc current into drivetrain [ A]
:
( )
( , )
_
,
_
=
=
⋅
⋅
=
motor
motor dc
dc motor motor motor
motor motor dc motor
motor dc
I
where
V T
I T V
η
η ω
ω ω
Equation 4- 19
The motor efficiency in Equation 4- 19 is taken from the motor efficiency map in
Figure 4- 7 for positive torque and positive speed ( 1st quadrant).
For the case of regenerative braking in hybrid vehicle designs, Equation 4- 19
changes to Equation 4- 20.
Motor efficiency in the mode of regenerative braking [ 1]
:
( )
( , )
,
_
=
⋅
⋅
=
regen
dc regen motor motor
motor motor dc motor
motor dc
where
V T
I T V
η
η ω
ω ω
Equation 4- 20
The motor efficiency in Equation 3- 20 is taken from the motor efficiency map in
Figure 4- 7 for negative torque and positive speed ( 4th quadrant).
82
4.3.2. Motor Controller and Motor Control Algorithm
According to the modeling philosophy, the control algorithms are separated from
the component descriptions. This principle is also followed through for the electric drive
train. The distinction allows greater flexibility and the use of advanced techniques such as
rapid prototyping.
The motor control algorithm determines how the acceleration pedal position and
the brake pedal position inputs determine the state of the electric motor, e. g. how much
torque is requested. In addition to this “ basic” functionality a number of safety and
convenience features could be programmed and their impact on the vehicle
characteristics tested. Generally, the algorithms could be either programmed in the
vehicle controller or in the motor controller. From a pure modeling point of view the
difference is not significant. However, in real vehicles, in some cases the supplier
situation might require that “ know how” be kept outside of the motor controller. If this is
the case, specific motor control algorithms could be realized in the vehicle controller. In
this work, it has been decided to place all motor related control algorithms into the motor
controller. Figure 4- 11 shows the graphical representation of the algorithm.
The overall algorithm splits up into two parts. The first part is responsible for the
operation of the electric drive system in the motor mode. The second part is responsible
for the operation of the electric drive system in the generator mode. The latter one is only
active in hybrid configurations that allow for the regeneration of mechanical power
during braking.
83
In the motor mode the relevant input variables are the motor speed, the motor
temperature ( or the temperature of the cooling system), the voltage at the dc- side of the
power electronics, and the acceleration pedal position.
In the generator mode the relevant input variables are the terminal voltage at the
dc- side of the power electronics, the motor speed, the motor temperature, and the brake
signal indicating the request for regenerative braking.
In the motor mode the normalized acceleration pedal position requests the fraction
of the peak motor torque available. This peak motor torque is a motor constant and is the
maximum torque the drive train is able to provide at zero speed and maximum dc voltage
at the dc side of the power electronics. This, by the driver requested torque value, can be
reduced by several factors:
• If the motor speed is too high, e. g. in downhill situations, the motor centrifugal forces
accessing the rotor increase and this increase could potentially damage the rotor.
Therefore it is necessary to limit the accelerating motor torque beyond a maximum
speed but below the critical motor speed that causes damage to the motor.
• If the motor temperature is too high, e. g. the losses in the electric motor led to an
increase in the motor temperature above the critical temperature.
• If the supply voltage is too low. This function is not for the protection of the electric
motor but for the protection of the power source ( fuel cell stack, battery or ultra-capacitor).
A too low voltage increases the possibility of cell reversal and with this a
potential damage at the supply side.
84
In the generator mode the normalized electric brake signal derived from the
normalized brake pedal position24 determines the fraction of the maximum torque the
motor is able to provide in the generator mode. This peak generator torque is the peak
torque the drive train is able to provide in the generator mode at zero speed and
maximum voltage. It is approximately the same torque as the maximum motor torque but
with the opposite sign. Just as in the motor mode, in the generator mode the requested
torque could be reduced and increased by several factors:
• if the voltage at the dc terminals of the power electronics is too high the generator
torque and with this the recharged power needs to be decreased. This functionality
protects the battery or ultra- capacitor storage from overcharging.
• if the temperature of the drive train or the associated cooling system is too high the
torque in the generator mode needs to be reduced to avoid damage
• if the motor speed is too high, e. g. in downhill situations, the increasing centrifugal
forces could destroy the electric drive train. To protect the drive train the generator
torque could be increased if the energy storage could accept the additional power.
The derived acceleration torque request ( in the motor mode) or the brake torque
request for the braking mode is then compared to the actual torque the drive train
provides. The result of this comparison is fed into a Proportional – Integral controller ( PI
– controller). The output of this controller is limited to upper and lower boundaries and
filtered through a first order transfer function, which represents low pass characteristics
of the control algorithm to avoid the impact of noise. Finally, the result of this algorithm
24 See chapter “ Vehicle controller.”
85
is the output of the motor controller and determines how much of the motor torque
available is requested.
An additional function, not realized yet but possible to add, is the mimic of the
compression torque of an IC- engine vehicle. Because of the fact that electric drive trains
have very few frictional losses, the idle characteristics of electric vehicles and IC- engine
vehicles are different. IC- engine vehicles decelerate if the acceleration pedal is released
due to significant air compression losses in the engine. In contrast, electric vehicles don’t
show this deceleration because no compression losses are present and other frictional
losses are small compared to the compression losses. Thus, for the driver of electric
vehicles, unfamiliar behavior might lead to driver decisions less optimal for the overall
energy consumption of the vehicle. If the driver sees an obstacle, e. g. a red light, he
releases the acceleration pedal. However, the vehicle decelerates at a much slower rate
than he is used to in IC engine vehicles. It is therefore possible that he approaches the
obstacle faster than he thought and is forced to perform a rapid ( last minute) braking
maneuver to avoid a collision. In this rapid braking maneuver most of the kinetic energy
stored in the vehicle mass is dissipated into heat in the friction brakes and not recovered
by generatoric braking. The overall energy balance would be more optimal if the driver
had decided to start a gentle braking maneuver as early as possible and recovered the
maximum of the kinetic energy stored in the vehicle with generatoric braking. However,
this driver behavior is unlikely because it is different from the conventional vehicles. For
driver assistance, a function that automatically switches the drive train into the generator
mode if the acceleration pedal is released could be implemented. In this case, the
86
requested brake torque simulates the compression losses of an IC engine vehicle. The
torque could be constant and speed independent or varying with vehicle speed.
motor
( speed to high)
max. brake torque
XXXX
voltage
( to low)
1
Tp+ 1
proportional-integral
controller
saturation filter
+
-
actual motor
torque
acc.
signal
brake
signal
XXXXX
+
+
voltage
( to high)
max. acc. torque
temperature
motor speed
( to high)
requested
torque
+
+
+
y y1
yout
Figure 4- 11: Motor control algorithm.
Equations 4- 21 to 4- 26 show the motor control algorithm illustrated in Figure
4- 11 in mathematical form.
During regenerative braking the requested torque is computed according to
Equation 4- 21.
87
( )
temperature variable
( ) reduction factor due to high temperature
( ) reduction factor due to high terminal voltage
maximum motor torque during regenerative braking
( , ) additional brake signal for simulating compression friction
( ) additional brake signal if motor speed is to high
brake signal generated by vehicle controller
requested torque for the mode of regenerative braking
:
( ) ( ) ( ) ( )
_
_ min
max_
_
_
_ _ max_ _ min _
=
=
=
=
=
=
=
=
= − + ⋅ ⋅ ⋅
ϑ
ϑ
ϑ
temperature high
voltage high ter al
regen
idle
speed high motor
request regen
request regen speed high motor idle regen voltage high ter al temperature high
r
r V
T
p v q
p n
p
T
where
T p p n p v T r V r
Equation 4- 21
During phases of acceleration the requested motor torque is calculated according
to Equation 4- 22.
( ) reduction factor due to low terminal voltage [ 1]
maximum motor torque during acceleration [ Nm]
acceleration signal generated by the driver [ 1]
requested torque in the acceleration mode [ Nm]
:
( ) ( ) ( )
_ min
max_
_
_ max_ _ _ min _
=
=
=
=
= ⋅ ⋅ ⋅ ⋅
voltage low ter al
accel
request accel
request accel accel speed high motor voltage low ter al temperature high
r V
T
q
T
where
T q T r n r V r ϑ
Equation 4- 22
The requests for acceleration and braking are summed25 and from the combined
request the actual motor torque is subtracted. The difference between the requested and
actual motor torque is the error and fed into the proportional integral controller ( Equation
4- 23). The output of this controller is limited to values between – 1 ( for maximum
generatoric braking and + 1 ( for maximum acceleration) and then fed through a first order
transfer function ( Equation 4- 24 and 4- 25). This transfer function can be interpreted in
several ways:
25 Normally either the request for braking or for acceleration is zero. However, the possibility that the
driver presses the acceleration pedal and the brake pedal at the same time is not excluded.
88
First it accounts for the filter time constants of the analog input low pass filters in
a real power electronic design.
Second it accounts for the time constant imposed by the motor coil inductivity
and resistance. The output of the motor control algorithm could be interpreted as an
analog signal that determines the state of the power switches and therefore controls the
average motor current.
( )( )
T actual motor torque [ Nm]
K Gain proportional integral controller [ 1/ Nm]
Time constant of proportional integral controller [ sec]
intermediate value [ 1]
:
actual
MC
MC
_ _
_ _
=
=
=
=
+ + −
+ −
⋅ = ⋅
τ
τ
y
where
T T T
dt
d T T T
T
dt
dy
K request brake request accel actual
request brake request accel actual
MC
MC
MC
Equation 4- 23
After the limitation block the intermediate value y changes to the intermediate
value y1.
intermediate request variable
:
1 1
1 1
1 1
1
1
1
1
=
= ≤
= ≥
= < <
y
where
y - if y -
y if y
y y if - y
Equation 4- 24
Finally the output variable determining the requested motor torque is stated in
Equation 4- 25. The variable yout determines the requested fraction of the maximum motor
torque available.
89
( ) request variable for motor torque [ 1]
filter time constant [ sec]
:
( ) ( )
( )
1
=
=
⋅ + =
y t
T
where
y t y t
dt
T dy t
out
filter
out
out
filter
Equation 4- 25
90
4.3.3. Transmission
The transmission modeled in this work is a 1- speed transmission including
differential. Input variables are the motor shaft speed and the motor shaft torque. The
output variables are wheel torque and wheel speed ( Figure 4- 12).
Figure 4- 12: Block diagram of the transmission model.
Similar to the electric drive train, the transmission translates energy flows in both
directions. During phases of acceleration or cruising with constant speed the energy flow
is from the motor to the wheels. During phases of deceleration in hybrid designs the
energy flow is reversed from the wheels to the electric motor.
The efficiency map has to describe both energy flow directions. Assuming that
the motor speed and vehicle speed in this model are always positive, the two directions of
energy flow result in a positive torque during acceleration phases and a negative torque
during phases of regenerative braking ( in hybrid designs only).
trans η
motor shaft
torque
motor
speed
wheel
torque
trans-mission
ratio wheel
speed
91
Transmission ratio [ 1]
Wheel torque [ Nm]
T Motor shaft torque [ Nm]
Mechanical power at the motor shaft [ W]
Mechanical power at the wheels [ W]
Transmission efficiency in regenerative brake mode [ 1]
:
_
_
_
_
trans_ motor
_
_
_
_
trans_ motor
=
=
=
=
=
=
⋅
= =
i
T
P
P
where
T i
T
P
P
trans wheel
trans motor
trans motor
trans wheel
trans motor
trans wheel
trans motor
trans wheel
η
η
Equation 4- 26
Transmission efficiency in regenerative brake mode [ 1]
:
trans_ regen
_
_
_
_
trans_ regen
=
⋅
= =
η
η
where
T
T i
P
P
trans wheel
trans motor
trans wheel
trans motor
Equation 4- 27
Equations 4- 26 and 4- 27 describe the efficiency for both cases. The model
assumes that the friction losses in the transmission are the same for both cases. These
assumptions allow mirroring the 1st quadrant of the map ( positive torque and positive
speed) into the 4th quadrant ( negative torque, positive speed). The complete efficiency
map for the transmission is shown in Figure 4- 13.
92
0 2000 4000 6000 8000 10000 12000
- 300
- 200
- 100
0
100
200
300
Shaft speed [ rpm]
Shaft Torque [ Nm]
0.96
0.95
0.94
0.930.92
0.93 0.92
0.94
0.95
0.96
Motor Mode
Generator
Mode
Figure 4- 13: Efficiency map of the 1- speed transmission including differential.
The inertia of the transmission is not explicitly considered in the transmission
block. However, the transmission inertia can be transformed without any constraints
either to the wheel side and added to the wheel inertia or to the motor side and added to
the motor inertia.
Equations 4- 28 and 4- 29 describe the transformation of the rotational inertia to the
wheel side or to the motor side for the case of the two- stage transmission ( reduction gear
and differential). Figure 4- 14 shows the rotational inertias at each stage.
93
wheels
i1 i2
motor
1 Θ
2 Θ
3 Θ
Figure 4- 14: Schematic of the transmission.
i Reduction ratio of the differential stage [ 1]
i Reduction ratio of the reduction stage [ 1]
Inertia of transmission components spinning with wheel speed [ kg m ]
reduced by the ratio i1 [ kg m ]
Inertia of transmission components spinning with the motor speed
Inertia of transmission components spinning with motor speed [ kg m ]
Total transmission inertia transformed to the motor side [ kg m ]
:
1 1
2
1
2
3
2
2
2
1
2
_ _
2 3
2
2 2
1
_ _ 1
=
=
Θ = ⋅
⋅
Θ =
Θ = ⋅
Θ = ⋅
  

  

Θ = Θ + ⋅ Θ + ⋅ Θ
trans motor side
trans motor side
where
i i
Equation 4- 28
( )
to the wheel side [ kg m ]
total transmission inertia transformed
:
2
_ _
1
2
2 1
2
_ _ 3 2
⋅
Θ =
Θ = Θ + ⋅ Θ + ⋅ Θ
trans wheel side
trans wheel side
where
i i
Equation 4- 29
94
4.3.4. Fuel Cell System
In this work, the term fuel cell system is used to refer to the combined system of
fuel cell stack, water and thermal management, air supply ( including compressor and
expander), and fuel processor ( including reformer, clean up stages, and the burner for the
anode off gas).
Origin and Development
The individual component models that comprise the overall fuel cell system have
different origins. Springer ( Springer 1993 and 1998) described the fuel cell model
fundamentals on the cell level. Friedman ( Friedman 1998) took the original Springer
model, expanded it to a complete stack model and programmed this into SIMULINK.
Cunningham ( Cunningham 1999) developed an air supply model for a direct hydrogen
vehicle. Combining the stack model and the air supply model Friedman ( Friedman 1999)
and Cunningham ( Cunningham 1999) developed an optimal operating strategy for the
overall system of fuel cell stack and cathode air supply for the direct hydrogen case.
Later, this initial model was expanded to cover the cases of indirect methanol fuel cell
systems and indirect hydrocarbon systems ( Friedman 2000). In addition, Cunningham
discussed the implications of an additional expander into the air system of a PEM fuel
cell engine ( Cunningham 2000). Badrinarayanan developed a water and thermal
management system, addressing the cooling loads and the issue of water sustainability. In
a second step, Badrinarayanan added water and thermal management implications to the
initial optimized operating strategy ( Badrinarayanan 2000). Friedman ( Friedman 2001)
provided a complete discussion of the optimal control strategy, including water and
th