QSS TB Manual
QSS TB Manual
QSS TB Manual
dv
w_wheel
w_wheel
dw_wheel
dw_wheel
dv
T_wheel
w_MGB
w_gear
dw_MGB
dw_gear
P_CE
P_f uel
liter/100 km
T_wheel
3.457
x_tot
Vehicle
T_MGB
T_gear
T ank
Display
x_tot
Driving Cycle
L. Guzzella, A. Amstutz
June 2005
Preface
This text describes the design and use of the second version of the QuasiStatic Simulation Toolbox (QSS
TB) which permits a fast and simple estimation of the fuel consumption for many powertrain systems. This
toolbox is used in ongoing research projects and in the exercises to the lecture "Vehicle Propulsion
Systems."
This is the manuals second version. The authors welcome any notifications of errors (in content or
terminology), suggestions for improvements or expansion, etc. (send an email to:
[email protected]).
The QSS TB is provided to students and other interested persons under the following conditions only:
1.
2.
This document is not entirely self-explanatory; at certain points, the consultation of the script to the lecture
"Vehicle Propulsion Systems" is necessary for comprehension.
A special thanks to Brigitte Rohrbach for the translation of this manual!
Contents
1
Introduction
1.1
1.2
1.3
Applications
3.1
3.2
3.3
3.4
References
List of Symbols
Latin
a
A
B
d
e
g
h
Hu
k
m
r
v
V
Vd
P
S
T
x
Acceleration
Surface
Bore
Diameter
Efficiency
Gravitation constant
Integration step size
Lower heating value
Computational step
Mass
Radius
Speed
Fuel consumption
Displaced volume
Power
Stroke
Torque
Distance
[m/s2]
[m2]
[m]
[m]
[-]
[kg*m/s2]
[s]
[J/kg]
[-]
[kg]
[m]
[m/s]
[kg/s]
[m3]
[W]
[m]
[Nm]
[m]
Greek
Efficiency
Density
Inertia
Rotational speed
[-]
[kg/m3]
[kg*m2]
[rad/s]
Acronyms
BT
CE
CVT
EG
EM
FC
MGB
SC
Battery
Combustion Engine
Continuously Variable Transmission
Electric Generator
Electric Motor
Fuel Cell
Manual Gear Box
Supercapacitor
Indexes
f
L
Vehicle
Air
Fuel
Introduction
1.1
Prerequisites
The following two conditions must be met for a user to work efficiently with the QSS toolbox (QSS TB):
Users must be familiar with Matlab/Simulink, on which this toolbox is based. A familiarity with
file handling, the execution of a simulation, and the presentation of results are minimum
prerequisites.
Users must have a basic understanding of the physics and the design of powertrain systems.
1.2
Since the basic principles of the QSS are discussed in detail in the script to the lecture "Vehicle Propulsion
Systems," our primary intention here is to show how the elements of the QSS TB can be linked.
The key idea behind the QSS TB is to reverse the usual cause-and-effect relationships of dynamic systems.
Rather than calculating speeds from given forces, based upon given speeds (at discrete times), the toolbox
calculates accelerations and determines the necessary forces.
Vehicle in the plane traditional approach:
System:
1
m v& f (t ) = Fa (t ) m f g cr L cw Af v 2f (t )
2
Cause:
Effect:
force Fa (t)
vehicle speed v f ( t)
1
m v& f (t ) = Fa (t ) m f g cr L cw Af v 2f (t )
2
1.3
An introductory example
Each program within the QSS TB consists basically of an .mdl file (Simulink) where the
system model is described (which contains the description of the drive assembly).
It is always good programming practice not to enter any numerical values for the parameters directly in
the .mdl file (even though that would easily be possible); rather, all parameter values can be easily entered
in each block of the model through an intuitive user-interface (so called mask).
The units and the remarks of the parameters are normally specified within the mask environment; since the
number of calculation steps is relatively small1, it is generally possible to do without normalizing them but
rather to work with SI units directly.
dv
dv
w_wheel
w_wheel
dw_wheel
dw_wheel
T_wheel
Vehicle
i
w_MGB
w_gear
dw_MGB
dw_gear
P_CE
T_wheel
i
P_f uel
x_tot
T_MGB
T_gear
3.457
liter/100 km
T ank
Display
x_tot
Driving Cycle
Fig. 1.3.1
First a drive cycle has to be chosen (EU cycle and FTP are typical candidates; however, any cycles
designed by users may of course be used as well). Within the function block "Vehicle" the torque at the
wheel (i.e. resistances plus acceleration) is calculated. While this torque is determined on the basis of the
gear selected, in the case of automatic transmissions it may also be determined online by a control system.
The transmission converts it to a demanded net engine torque. From the total torque, which consists of net
torque plus acceleration torque, the IC engine then "produces" an amount of fuel consumption. Within the
block called "Tank" those consumption data are summarized and converted to a consumption figure in
liters per 100 km.
The detailed explanation of the various blocks in Fig. 1.3.1 will be given in Chapter 2.
To accede the mask in order to change the parameter values, simply double-click on the corresponding
Simulink block. An environment similar to the one shown as an example in Fig. 1.3.2 allows the user to
enter the desired values.
This is no longer the case if the program contains a large number of implicit equations.
Fig. 1.3.2
Referring to the example of Fig. 1.3.1, the following parameter values have to be entered in the mask of
the corresponding block:
Driving Cycle:
Parameter
Value
Choose a cycle
Europe NEDC
ON
Vehicle:
Parameter
Value
750
1.8
0.5
0.22
0.008
Value
1. gear [-]
15.174
2. gear [-]
8.338
3. gear [-]
5.378
4. gear [-]
3.937
5. gear [-]
2.748
Efficiency [-]
0.98
300
Combustion Engine:
Parameter
Value
Engine type
Otto
Displacement [l]
0.708
0.05
105
2600
300
ON
Tank:
Parameter
Value
Fuel
Gasoline
ON
The exact significance of each parameter is discussed in more detail in Chapter 2. Notice, however, that
even for this relatively simple example a significant number of parameters must be known.
Figs. 1.3.3 through 1.3.5 show a few typical results of these calculations. It may not be immediately
apparent just how easily so-called "what-if" questions for parameter variations can be answered (e.g.,
concerning sensitivities). Even questions regarding structural variations (e.g., standard shift vs. CVT) can
be investigated with just slight changes within the .mdl file.
10
1.2
0.8
0.6
0.4
0.2
200
Fig. 1.3.3
400
600
Time [s]
800
1000
1200
10
9
8
7
6
5
4
3
2
1
0
200
Fig. 1.3.4
400
600
Time [s]
800
1000
1200
1
0.9
0.8
0.7
DT,trac [-]
0.6
0.5
0.4
0.3
0.2
0.1
0
600
Fig. 1.3.5
700
800
900
Time [s]
1000
1100
1200
Efficiency of the drivetrain during the last city and extra-urban portions (only
traction phase considered)
11
2.
The various elements of the QSS TB library are grouped according to their function as depicted in Fig.
2.0.1. To open a group of elements, double-click on the corresponding block.
Fig. 2.0.1
In the following sections each group of elements of the QSS TB library will be analyzed in detail.
12
2.1
Driving Cycle
A comparison of the fuel consumption data of various drive systems only makes sense if those data are
acquired during a normalized test drive, a so-called test cycle. Typically, Europeans use the EU cycle,
whereas the U.S. use the FTP cycle. It is generally known that these cycles tend to be on the "soft" side, i.e.,
the data for acceleration and top speeds frequently are exceeded in daily driving. The use of proprietary test
cycles may thus make more sense.
A cycle is defined by at least two vectors:
1.
a time vector (in which the time spans usually are equal), and
2.
a vehicle speed vector v f (k h) .
The acceleration is calculated from the vehicle speed on the basis of the following equation:
a f (k h) =
v f (k h + h) v f (k h)
, k = 1, kmax 1,
a f (k max ) = 0,
h
(2.1.1)
The acceleration here is treated "predictively" whereas it may also be treated "retrospectively," as follows:
a f (1) = 0,
a f (k h) =
v f (k h) v f (k h h)
h
, k = 2, k max
(2.1.2)
In the QSS TB package the most frequently used driving cycles are already defined, i.e. the corresponding
time, speed, and gear vectors of cycles such as EU or FTP are already saved in the folder
\Data\DrivingCycles. Therefore the user may choose to work with the desired driving cycle.
Of course there is the possibility to define own cycles; this would require the definition of two or three
vectors of equal length. The gear values would not need to be predefined. A CVT may be represented by
taking a conventional transmission (cf. Sec. 2.4 below) whose gear ratio is given by a control unit (Sec. 2.7
below).
Please refer to the Chapter 4 Customizing the QSS Toolbox Library for further information.
This text uses explicit names for the parameters, if at all possible those used in the .m file of Sec. 1.2 above. Obviously, these names may be chosen at will or redefined, as long as they are used consistently. The only exception is
the step size h which may not be changed.
13
V_z
x_tot
Integration
4
x_tot
x_tot
t
Clock
Speed
v
v
T im e
Dem ux
V_z
D _z
Differentiation
Cycle data
Gear ratio
2
dv
dv
3
i
i
Fig. 2.1.1
Schematic representation of the block "Driving Cycle" with given gear values
Fig. 2.1.2
14
2.2
Vehicle
1
v
1/r_wheel
v _a
w_wheel
Average speed
w_wheel
1/r_wheel
dw_wheel
P_wheel
m _f*g*m u
Rolling resistance
v
r_wheel
F_aero
3
T _wheel
Aerodynam ic resistance
2
dv
d_v
Wheel radius
F _iner
Inertia
T _wheel
T otal resistances
P_roll
P_aero
P_iner
Fig. 2.2.1
15
The vehicle inertia reflects the mass of the vehicle (without wheels) plus the wheel inertia data (parameter
Rotating mass [%] in the mask of Fig. 2.2.2 below), as follows:
2
m f + 4 wheel / rwheel
(2.2.1)
Notice that any additional inertia, such as engine, flywheel, etc., are not included in this block. They will be
represented in their own respective blocks later on.
Fig. 2.2.2
16
2.3
Energy Converter
There are three types of energy converters included in the QSS TB library:
1.
2.
3.
Combustion Engine
Electric Motor and Generator
Fuel Cell
Notice that only the combustion engine and the fuel cell can be directly connected to an energy source (fuel
tank), i.e. they can directly produce a fuel consumption.
17
w_CE
T_C E
1
w_gear
Lower l im i t
(speed at idle)
w_CE
H_u
T _gear
2
Lower l im i t
(fuel cutoff)
theta_CE
dw_gear
Engi ne inertia
Fuel lower
heati ng value
T _CE
Engi ne consum ption m ap
V = f(w, T )
[kg/s]
T otal torque
w_C E
P_CE
T_C E
P_C E
Detect i dle
T_CE
1
P_CE
P_CE
P_aux
T otal power
Fig. 2.3.1
1
w_CE
P_CE_idle
M axim um torque
ST OP
|u|
T _CE
2
w_CE
Idl e detection
T _CE
1
P_CE
w_CE_upper
ST OP
1
P_CE_fuel
Fig. 2.3.2
Consumption at idle
Idle speed is detected as soon as the demanded rotational speed of the engine falls below the limit
w_CE_idle and simultaneously the demanded torque value drops below the limit T_CE_idle (typically
zero, cf. Fig. 2.3.2, left). In this case, the engine power value is set to P_CE_idle. Fig. 2.3.1 shows that
the overrun fuel cutoff is given a higher priority, which means that as soon as the torque value at idle speed
falls below the fuel cutoff limit, the fuel cutoff is activated.
Consumption maps
For the reasons addressed in depth in the lecture "Vehicle Propulsion Systems", the QSS TB uses twodimensional fuel consumption maps:
18
(2.3.1)
Table 2.3.1
These values do not have to be equidistant, but they must increase strictly monotonously.
19
Fig. 2.3.3
The user interface (mask) of the Combustion Engine block based on consumption
map
pme = e pm pme 0
(2.3.2)
where pme is the brake mean effective pressure, i.e. a normalized formulation of the engines torque
pme =
and
pm
(2.3.3)
pm =
20
TCE 4
Vd
m H u
Vd
(2.3.4)
The brake mean effective pressure is the pressure that has to act on the piston during one full expansion
stroke to produce the same amount of work as the real engine does in two engine revolution (a four-stroke
engine is assumed here); the fuel mean effective pressure is that brake mean effective pressure that an
engine with an efficiency of 1 would produce with the fuel mass m burnt per engine cycle.
Therefore the engines efficiency can be written as
CE =
pme
pm
(2.3.5)
In Eq. (2.3.2) the coefficient e represents the thermodynamic properties of the engine (related to the
indicated mean effective pressure) and pme 0 represents the engines losses (due to friction and gas
exchange)
(2.3.6)
The friction mean effective pressure is calculated using the ETH friction model described in [1]
2
pme 0 f = k1 ( k2 + k3 S 2 CE
) max
k4
B
(2.3.7)
Table 2.3.2
Parameter
k1
k2
k3
k4
Diesel
1.44 * 105 [Pa]
0.50 [-]
1.1 * 10-3 [s2/m2]
0.075 [m]
PCE = CE Pgear
(2.3.8)
where the power delivered from the gear box is defined as:
(2.3.9)
Fig. 2.3.4 shows an overview of the QSS TB model of the IC engine based on the Willans approximation.
Notice the similarity to Fig. 2.3.1.
21
1
w_gear
Lower lim it
(speed at idle)
w_CE
w_CE
eta_C E
T _gear
T_CE
theta_CE
dw_gear
Engine inertia
Lower lim it
(fuel cutoff)
T _CE
Engine efficiency
w_C E
T otal torque
P_C E
T_CE
P_C E
Detect idle
T_CE
1
Detect fuel cutoff
P_CE
P_CE
P_aux
T otal power
Fig. 2.3.4
Top view of the model Combustion Engine based on the Willans approximation
1
2
4*pi*u/V_d
T _CE
p_m e
w_CE
eta_CE
u/e
p_m f
p_m ef
p_m e0g
p_m e0
Fig. 2.3.5
22
Fig. 2.3.6
The user interface (mask) of the Combustion Engine block based on the Willans
approximation
23
w_EM
T_EM
Detect overload
and overspeed
1
w_gear
w_EM
Efficiency
eta = f(w, T )
theta_EM
dw_gear
T _EM
3
T _gear
T otal torque
1
P_EM
P_EM
P_aux
T otal power
Fig. 2.3.7
The characteristics of electric motors may be entered in the model directly since they do not contain any
singularities. The electric power required within the first quadrant (EM > 0 and TEM > 0) can thus be
expressed as follows:
PEM = EM TEM
24
EM (EM , TEM )
(2.3.10)
or, in the second quadrant4 (EM > 0 and TEM < 0),
(2.3.11)
respectively.
To avoid having to keep distinguishing between these two cases, equations 2.3.10 and 2.3.11 can be
combined into a single efficiency map as shown in Fig. 2.3.8, with Eq. 2.3.11 being used for both quadrants.
T EM
Nm
60
1.4
1.3
40
1.2
1.15
20
100
200
-20
0.83
Fig. 2.3.8
0.87
400
500
EM rad / s
0.77
-40
-60
300
0.71
The design and data structure of this program map is identical to the one in IC engines, even though
physically they have different meanings, i.e., the block "Efficiency" in Fig. 2.3.5 contains
a 1 x n vector "w_EM_row" containing the support points of the rotational speed of the
electric motor
an m x 1 vector "T_EM_col" containing the support points of the motor torque
an efficiency map n x m "eta_EM_map" representing the efficiencies of the relative
combination of torque and rotational speed being considered.
An electric generator is described simply by the lower half of the second quadrant of the motor map shown
in Fig. 2.3.8. With one exception, the remainder is unchanged. The exception is that since electric
generators can be used only within the context of serial hybrid structure, i.e., in connection with a prime
mover (e.g., IC engine, gas turbine, etc.), the sole function of the generator is to generate electric power
from mechanical energy. Thus the inertia of the generator can always be included in the prime mover
elements and therefore the block "Electric Generator" does not require an acceleration input of its own.
Since driving in reverse is meaningless for the calculation of average fuel consumption, the third and
fourth quadrants are not considered here.
25
Electric motors are scaled using a "mean effective pressure" formulation similar to the one common for IC
engines or by simply scaling the support vectors and assuming the motor efficiencies to remain unaffected
by that operation.
Fig. 2.3.9
26
Pump
Hydrogen
tank
Heat
exchanger
EM
Fuel-cell stack
Compressor
EM
Water trap
Air
Fig. 2.3.10
"Turbine"
The energy conversion in a fuel cell depends on its electrodes being supplied with hydrogen and air or
oxygen. The supply of the former is ensured if hydrogen is furnished from a tank within the vehicle as the
fuel cell simply "draws" the amount it requires. The supply with air is more complicated. Under dynamic
conditions the amount and pressure of the air depend on the load at the fuel cell. Depending upon response
times, air mass flows, and charge-air pressures, the compressor may require an amount of electric power
that severely affects the total efficiency of the drive system.
Modeling of a fuel cell
Just as in a battery, the voltage in a fuel cells decreases under load conditions. The maximum power usually
is reached at around 0.5 to 0.6 V single cell voltage. The voltage drop is a function of the current and the
internal resistance of the cell (on either side of the electric motor), of the kinetics of the electrode (primarily
on the oxygen side), of limitations present in the gas supply, and of the water discharge on the oxygen side
of the fuel cell. A voltage level that is practically utilizable is reached by stacking fuel cells in a serial
configuration. Such a fuel cell stack, however, must take into account the temperature and humidity control
of the reaction gases and it must enable the controlled transport of the heat, water, and electrical energy
thus generated (cf. Fig. 2.3.11).
H2
Air
H O
2
N2
Fig. 2.3.11
H2
Air
H2
Air
H2 O
H2 O
N2
N2
H2
Air
H O
2
N
2
H2
Air
H2
Air
H 2O
H2 O
N2
N2
27
Ifc
V0
Fig. 2.3.12
Rfc
Vfc
Since the resistance Rfc is a function of the area Ffc of the exchange membrane described above, the current
is usually normalized to Ffc, i.e.
I fc
(2.3.12)
i fc =
F fc
yielding, in a first approximation, the following voltage for the fuel cell:
V fc = V 0 R fc F fc i fc = V0 R fc ifc
(2.3.13)
With reference to Fig. 2.3.14 below, the variable V0 represents the voltage at which the ideal characteristic
intersects the abscissa at ifc = 0, rather than the theoretical voltage with the fuel cell. (For a detailed
explanation, please refer to the lecture "Vehicle Propulsion Systems."). The resistance R% fc [ m2] is
constant for any one fuel cell type and thus no longer a function of the surface area of the cell membrane.
As described above, a so-called stack (cf. Fig. 2.3.13) is obtained when a number of fuel
cells are serially linked. The stack voltage is
V fc, stack = N V fc
(2.3.14)
If several stacks are joined in parallel, the model described above would still be valid. However, the
increase of the fuel cell area would lead to an increase in current.
V0, stack
Rfc, stack
Vfc, stack
Fig. 2.3.13
V0
....
Rfc
V0
Rfc
V0
Rfc
Vfc, stack
The model of a fuel cell stack in the QSS TB assumes that a power amplifier adjusts the voltage level
automatically. The current level Ifc within the fuel cell can thus be represented by the following equation:
I fc =
Pex Pvc
,
V fc
(2.3.15)
where the variable Pex represents the current demanded and Pvc the amount of the losses within the internal
condenser. However, since the voltage in the denominator of (2.3.15) is a function of the fuel cell current
(see eq. (2.3.13)), eq. (2.3.15) results in an implicit equation.
28
For the approach shown in eq. (2.3.13), this loop may be resolved. However, since at small current
densities especially, the relationship Vfc(ifc) is extremely nonlinear and significantly deviates from those
results, the QSS TB model does not attempt to resolve it. Instead, an additional delay is introduced (cf. Fig.
2.3.15) which breaks that implicit loop.
A fuel cell produces significant amounts of heat as well:
Ploss = V th V fc N I fc
(2.3.16)
Vth
1.0
Vfc
V0
Volt
ifc
~
Rfc ifc
0.3
1000
Fig. 2.3.14
6000
A/m 2
ifc
i fc, max
A number of parameter values typically seen in such a fuel cell model are shown in Fig. 2.3.17. Figure
2.3.16 finally shows the model for the intake air compressor.
1/V_th
T heoretical cell voltage
P_loss
V_th
Heat losses
N_FC
i_FC
Supervision
of current density
P_in
1/A_FC
N_FC
P_FC_idle
Stack current
V_FC
Fuel cell
m odel
[A/m ^2]
I_FC
1
z
Stack voltage
i_FC
1
P_FC
P_FC
E-M otor is disengaged, as soon as required power
is <= P_fc_idle (->idle speed energy consum ption)
P_EM_C
P_FC
Fig. 2.3.15
29
Air m ass fl ow
1
1/eta_EM _C
del ta_h_C_air
l_air
M _air
100/21
1/2
1/H_o_m
P_EM _C
P_EM _C
Air enthalpy
Fig. 2.3.16
Fig. 2.3.17
30
M olecular weight
Inverse O2
fraction
1
P_FC
2.4
Gear System
The transmission of mechanical work between different levels of torque or rotational speed, respectively, is
possible due to the following three building blocks:
simple transmission (i.e., fixed relationships between torque levels or rotational speed levels)
manual gear box (i.e., a finite number of relationships between torque levels or rotational speed
levels)
CVT (i.e., continuously variable relationships between torque or rotational speed levels,
respectively).
Manual gear boxes and CVTs can be controlled either by the drive cycle block, i.e. the gear ratios are
defined a priori, or by an online controller.
1
1
w_wheel
w_trans
w_trans
2
2
dw_wheel
dw_trans
P_trans
w_wheel
T_wheel T_trans
T _wheel
gear_ratio
3
T _trans
gear_ratio
T _trans
Power flow
Fig. 2.4.1
In all three types of gearbox systems, all losses are described by an affine relationship
Pout = e Pin P0
(2.4.1)
where Pout and Pin represent the power leaving and entering the system, respectively. Since it is possible
that the flow is reversed (e.g., between the two phases "drive" and "fuel cutoff"), equation 2.4.1 has to be
interpreted case by case. Fig. 2.4.2 shows the solution presented by the QSS TB for the simplest case.
Equation 2.4.1 is solved within the third level, once with the driving element being the torque on the engine
side (i.e., force flowing from the engine to the wheel), and once with the driving element being the torque
31
on the side of the wheel. The relationships resulting therefrom are shown in Fig. 2.4.3, whereby it is to be
are negative, i.e., the
noted that in the case of the power direction wheel-to-engine, the idle speed losses P
0
= P holds ( P represents the idle speed loss in the "normal" case of the power flowing in
relationship P
0
0
0
the engine-to-wheel direction).
w_wheel
w_wheel
T_wheel
T_trans+
gear_ratio
Energy
Engine -> Wheel
2
T _wheel
T _trans
w_wheel
T_wheel
3
gear_ratio
Fig. 2.4.2
T_trans-
gear_ratio
Energy
Wheel -> Engine
1
w_wheel
inf
2
P_GT 0
T _wheel
1
w_wheel
e_GT
inf
T _wheel
1
T _trans+
3
gear_ratio
Fig. 2.4.3
32
P_GT 0
T _trans-
e_GT
3
1/e_GT
gear_ratio
Fig. 2.4.4
w_wheel
w_M GB
w_M GB
2
dw_wheel
dw_M GB
4
i
i_1
P_M GB
w_wheel
i_2
i_3
M ux
M AT LAB
Function
M anual Gear Box
i_4
T_MGB
3
T _M GB
gear
inf
i_5
T_wheel
T _wheel
T _M GB
Power flow
i_diff
M ux
Fig. 2.4.5
Top level of the block Manual Gear Box: notice the similarity with Fig. 2.4.1 and
the Matlab function to compute the actual gear ratio
33
Therefore an additional input, i.e. the gear number generated by the Driving Cycle block (see section 2.1
above) is needed. An m-function named manual_gearbox located in the folder \Functions computes
the gear ratio at the actual cycle time (see Fig. 2.4.5).
Fig. 2.4.6
34
w_wheel
w_CVT
w_CVT
5
dj_CVT
dw_CVT
dw_wheel
4
j_CVT
P_CVT
w_wheel
3
T _wheel
T_wheel
T_CVT
3
T _CVT
j_CVT
T _CVT
Power flow
Fig. 2.4.7
Top level CVT block, the remaining blocks being identical to those of Figs. 2.4.2 and
2.4.3
Comments:
So far, the parameters of the gearbox efficiencies e and P0 have been modeled as being invariable, in
particular, as being independent of the gear ratio. However, it would be quite simple to extend the system to
consider such variations as well.
The gear systems discussed thus far have all been mechanical. The QSS TB has not been including any
hydrodynamic torque converters, as they are not candidates for use with highly economic drive systems.
However, it would be easy enough to derive the respective models.
Fig. 2.4.8
35
2.5
Energy Buffer
There are two types of energy buffers included in the QSS TB library:
1.
2.
Battery
Supercapacitor
2.5.1 Battery
The models of batteries are designed in accordance with the approach introduced in the lecture "Vehicle
Propulsion Systems", i.e., the electric power "P_BT" flowing into the battery (negative when loading,
positive during discharge) represents the input, while the actual battery charge "Q_BT" represents the
output. Fig. 2.5.1 shows the top level of the battery model. Beyond the battery model proper (gray shading),
this block calculates the amount of electric power (in kWh per 100 km) drawn up to a certain instance
("Q_BT_IC" representing the initial charge of the battery).
1/Q_BT _0
q_BT
Q_BT _IC
U_BT _0/3.6e1
1
z
Battery charge
Q_BT
V_BT
Q_BT
Q_BT
U_BT
U_BT
2
x_tot
1
P_BT
Fig. 2.5.1
P_BT
P_BT
I_BT
I_BT
Battery voltage
Top level of the battery model, calculation of power drawn in kWh / 100 km
The basic idea behind the battery model is to integrate the power (in accordance with the QSS approach)
after calculating it from the known power and actual voltage of the battery, in order to then be able to
calculate the actual battery charge therefrom. The voltage depends on the battery charge, which is easy to
determine, and from the current charging or discharging the battery which unfortunately is not yet
known. This second dependency thus leads to an implicit equation for the battery power. Although the
solver in Simulink frequently is able to solve such equations, it is advantageous to first obtain a closedform solution to this implicit loop. This is the case especially whenever the battery is being utilized in an
infeasible operating mode. These derivations are shown below.
First, the modes "Charging," "Discharging" and "Idle" must be distinguished. Whereas the parameters
usually vary in the first two modes, in "neutral" the terminals just show the idle voltage of the battery.
36
As shown in Fig. 2.5.2, it is mandatory to keep close tabs on the battery since neither extremely high charging nor discharging loads are permissible (details are shown below). The block Supervision is designed
to assume this supervising function.
Q_BT
Enable charging
P_BT
U _BT
e_E
I_BT
Q_BT
Q_BT
Supervision
battery
U _BT_L
P_BT
Charging
Enable discharging
2
P_BT
e_E
P_BT
1
U_BT
Q_BT
U_BT_E
P_BT
Discharging
Enable idle
P_BT
e_Z
Q_BT
U_BT_E
Idle
Fig. 2.5.2
I_BT
q ( k h) =
Q ( k h)
, Q(k h) = Q(0) + i (k h) h
Q0
k
(2.5.1)
C rate:
i(k h)
Q
, i0 = 0
i0
1 h
( i0 fully charges an empty battery in one hour )
c(k h) =
(2.5.2)
They allow the use of the typical approach (affine in the charge ratio) to calculate the battery load
uBL (k h) = u1 L (c(k h)) q(k h) + u0 L (c(k h))
(2.5.3)
whereby the two weights u1L and u0L depend on the C rate as well
u1L (c(k h)) = cL 4 c(k h) + c L3 ,
(2.5.4)
37
The equations for the mode "Discharging" are similar, except for the parameters in Eq. (2.5.4) where
obviously the C rate is negative
u1 (c(k h)) = c E 4 c(k h) + c E 3 ,
(2.5.5)
The eight coefficients in Eqs. (2.5.4) and (2.5.5) may not be chosen entirely freely. For continuity reasons,
they must fulfill the following conditions:
c E1 = c L1 ,
cE 3 = cL 3 .
(2.5.6)
Based upon the power (Eq. (2.5.3)) and the voltage (Eq. (2.5.4)) of the battery, the value of the current flow
in or out of the battery, respectively, can be eliminated, which permits the presentation of the voltage as a
function of power only. For the charging mode the following relation is obtained:
1
2
The ambiguity in the solution of the quadratic equation obtained can be resolved using physical arguments.
uBE (k h ) =
The solution for the discharging mode is obtained following the same approach. These two equations are
then incorporated in the programs of the blocks "Charging" and "Discharging", respectively.
The maximum storage capacity of a battery sets physical limitations to the amount of positive power (in the
"Charging" case) that may enter the battery. For reasons of simplicity, it is assumed that a constant
maximum current cannot be exceeded, or else the simulation is terminated.
In the opposite case ("Discharging"), the amount of current a battery can deliver is limited by the internal
resistance that is always present. As stated above, the power delivered by a battery is given by
PBE (k h ) = u BE (k h ) i(k h) .
(2.5.8)
uBE (k h ) u Ei (k h )
.
(2.5.10)
REi (k h )
Deriving Eq. (2.5.10) from the voltage uBE, we state that the maximum of the amount of discharge power
(i.e., the minimum level of PBE) is delivered at a terminal voltage that is one-half the amount of the internal
voltage:
PBE (k h ) = u BE (k h)
1
1 u2
*
(2.5.11)
u Ei
PBE = Ei .
2
4 REi
Therefore, it is clear that the battery is never able to deliver more than P*BE. The model verifies this basic
limitation by terminating the simulation as soon as the value of P*BE is reached.
*
uBE =
The last point to be addressed is the question of the efficiency of a battery. It is not an obvious quantity, especially it may be defined locally or globally (over an entire cycle, i.e., the total power drawn from the
battery during a test drive divided by the energy required to recharge it). In the local approach, it is
assumed that within one time step h the battery is charged by a constant current, only to be discharged in
the next step by the same current:
38
BT =
(2.5.12)
The local efficiency thus is a function of the current charging or discharging the battery, respectively, and
of the actual battery charge level BT(c, q). The example depicted in Fig. 2.5.3 shows such an efficiency
map for a good battery and how strongly the efficiency depends on the C rate (or internal resistance) rather
than on the weak relationship to the charge level.
0.65
0.70
1.4
0.75
1
0.80
0.85
0.6
0.90
0.95
0.2
0.1
Fig. 2.5.3
0.3
0.5
0.7
0.9
Local efficiency map of a battery; charge level 10% 90%; C rate 0 200%
Comments:
The model described above is valid only for the normal operating range of the battery, i.e. between
approximately 10% and 90% of its nominal capacity. Outside of this range, rather strong nonlinear effects
may be observed. However, it is a well-known fact that batteries should not be operated in those outside
ranges due to serious effects on their longevity, efficiency, etc.
During the vehicle acceleration phase, batteries are subject to rather brief, but high peaks of energy
demands which either overload them or are the reason for a vehicle being equipped with unnecessarily
large batteries. This situation may be avoided by the installation of so-called supercapacitors, which are
capacitors with very large capacity (cf. Sec. 2.5.2 below).
The electronic power system controls the amounts of the current running between the battery and other
electrical components as well as among those components themselves. The details of these losses are not
being considered or modeled separately; rather they can be ascribed to the losses of the motors or
generators.
39
Fig. 2.5.4
2.5.2 Supercapacitor
Supercapacitors (or supercaps) can store energy in electrostatic fields and are able to attain very high
power densities (realistically around 1 kW per kg). Although their energy densities are moderate (i.e., 25
Wh/kg), their high power density still makes them ideally suited to function as electrical "peak shavers." If
they are used together with batteries, they can thus contribute to a lower battery weight and an efficient use
of energy.
The simplified model used in the QSS TB is shown in Fig. 2.5.5. The electrical power output, as demanded
by a controller, is converted using the voltage U, resulting in a corresponding current flow ISC.
PSC
Fig. 2.5.5
40
ISC
RSC
LE
USC
CSC
Schematic flow diagram of the model of the "supercap" (LE = power amplifier)
The charge QSC stored within the "supercap" is related to the inner voltage USC as follows:
USC =
1
QSC
C SC
(2.5.13)
1
(2.5.14)
P = RSC ISC +
QSC ISC
C SC
The power output is prescribed by the controller, while the charge QSC is defined by the memory of the
"supercap" (the charge being a state variable). The only remaining unknown is the current flow, which is
calculated as follows:
2
QSC
QSC
&
QSC = I SC =
+ 4 P RSC
CSC
CSC
( 2 RSC )
(2.5.15)
whereby physical arguments preclude the negative sign before a square root.
Fig. 2.5.6 shows how this relationship is presented in the QSS TB. The block "Supervision" tests whether
the "supercap" is being used within its permitted operating range, i.e., analogously to batteries, the amount
of power drawn from a "supercap" cannot exceed the amount lost due to internal resistance. Details are
shown in Fig. 2.5.7 below.
1
P_SC
M ux
(-u[2]/C_SC+sqrt(u[2]^2/C_SC^2-4*R_SC*u[1]))/(2*R_SC)
1
Q_SC
I_SC
z
SC charge
1/C_SC
1
U_SC
Q_SC
U_SC
P_SC
Supervision
supercap
Fig. 2.5.6
Top level of the hierarchy within the "Supercap" model of the QSS TB
41
1/C_SC
Q_SC
ST OP
U_SC_m ax
u2
ST OP
2
4*C_SC^2*R_SC
P_SC
ST OP
P_SC_m ax
Fig. 2.5.7
Fig. 2.5.8
42
Block Supervision
kcs = 1.15
P_f uel
(2.6.1)
1/rho_f
m _f uel
P_fuel
Integration
k_cs
1e5
2
x_tot
Fig. 2.6.1
Fig. 2.6.2
1
liter/100 km
V_liter
43
2.7
Controller
Control systems in the QSS TB can be simple or quite complex. One example of the former is a system for
which it is assumed that the demanded engine load is always present (cf. Sec. 1.3 above), whereas the
control system of the series hybrid system described in Sec. 3.1 below is an example of a more complex
system. The purpose of control systems in general is to process system data, external inputs (e.g. during
simulations), and cycle data (i.e., control instructions set a priori), generating input data for the various
system modules (see Fig. 2.7.1) such as engine speed, acceleration, or torque.
Other modules
System data
, ,
Exogenous data
Fig. 2.7.1
Control
(can have
internal states)
Module 1
, ,
Module n
A control system in which input changes immediately affect the output (i.e., no storage device in-between)
frequently contains implicit loops. Generally, the built-in Simulink solver is able to deal with those.
However, whenever possible, it is preferable to try to avoid such loops.
Another reason why control systems sometimes are provided with a "memory" is the presence of state
automata, or when the control system must be enabled to act preemptively. For instance, external data of a
drive cycle must be detected and processed before they influence the vehicle.
With reference to Sec. 2.4.3 above, Fig. 2.7.2 shows an example of a control system for a CVT. The output
data from a block "Driving Cycle" are provided to the "real" vehicle with a delay of one step size while
they simultaneously are being processed within the control system without any delay whatsoever. The
vehicle model contained in the control system computes the required drive power for any point in time. The
controller determines the rotational speed at which that power is best generated by the engine, taking into
account such goals as minimum consumption, running smoothness, as well as gear ratio limitations of the
CVT.
A real CVT control system could look similar. The controller inputs would include such data as rotational
speeds of the wheels and the engine, and the drivers torque demand as expressed by the gas pedal position.
The output would include the change in gear ratio, whereas the gear ratio itself would be its integral value.
1
z
Del ay v
1
v_delay
1
z
Delay dv
2
dv_del ay
eps
dv
T_wheel
dv
44
w_opt
j_CVT
j _CVT
1/h
4
dj_CVT
Fig. 2.7.2
1
z
Delay j
w_wheel
dj_CVT
Control system of a CVT with delays, vehicle model, and CVT gear ratio
optimization
The engine map for the EU cycle shown in Fig. 2.7.3 takes the vehicle example from Sec. 1.3, but includes
a CVT and the control system from Fig. 2.7.2. It shows two different cases: One is a CVT with a realistic
gear ratio band of 1:5 (with the characteristic data encircled), whereas the other is a CVT with an
unrealistic ratio of 1:7.5 (data marked with green "+" signs). The red curve designates the operating points
the control system considers to be optimum (cf. block "w_opt" in Fig. 2.7.2 above).
The deviations of the operating points calculated from those on the optimum curve are explained as follows:
The bandwidth is limited, which means that the optimum is not attainable for all points in the cycle.
(The "+" case shows that these deviations do not occur when the spread is sufficiently large.)
Losses within the CVT must be compensated by additional engine power.
The calculation of the actual load included the vehicle, but none of the inertia within the powertrain
or engine for which the additional accelerating power is required to overcome it.
60
0.32
50
TCE [Nm]
40
0.3
30
0.2
0.275
20
10
0.1
0
100
200
300
400
500
600
700
800
CE [rad/s]
Fig. 2.7.3
Program map of a CVT drive system; CVT gear ratios: blue o = 1:5, green + = 1:7.5
The fuel consumption data for the EU cycle for the case of the gear ratio bandwidth 1:7.5 are about 8%
lower than those measured at the 1:5 bandwidth, which is a noticeable improvement.
45
Fig. 2.7.4
46
Applications
3.1
This example is based only on those elements that are included in the QSS TB. Our goal is to design a
series hybrid vehicle that runs the internal combustion engine only at its good operating states. In particular,
part-load losses are to be avoided5. As the vehicle is able to produce its own electricity (via its so-called
"range extender" group), the battery capacity can be designed much smaller than it would have to be in a
purely electric vehicle, which of course results in a lower battery weight.
The top level of the model is shown in Fig. 3.1.1, where the elements introduced above are evident in the
arrangement suitable for the type of vehicle to be designed. The linkages of the electrical components are
especially noteworthy as the sum of the three electric power systems (i.e., starter motor, generator, and
battery) must always amount to zero. The power system which takes care of the necessary adjustments of
the voltage level and of the control of the power flow is assumed to be ideal and is thus neglected here.
dv
dv
w_wheel
dw_wheel
T_wheel
Vehicle
i
w_wheel
w_gear
dw_wheel dw_trans
dw_gear
T_wheel
T_gear
T_trans
T ransm ission
Vehicle-EM
w_wheel
x_tot
w_trans
w_trans
Electric M otor
w_gear
dw_wheel dw_trans
Driving Cycle
T_wheel
T_trans
T ransm ission
CE-EG
Q_BT
Fig. 3.1.1
Q_BT
x_tot
V_BT
Battery
P_EG
Electric Generator
Electric power balance
w_gear
dw_ctrl
dw_gear
Battery Controller
P_BT
T_gear
w_ctrl
T_ctrl
P_EM
P_C E
T_gear
P_f uel
x_tot
liter/100 km
T ank
2.11
Display
The various elements of this model are scaled-down versions of the basic elements. The following points
are worth mentioning:
The "range extender" block is designed for a minimum of 20 kW, which allows the vehicle to reach
a (theoretical) top speed of approximately 140 km/h.
The internal combustion engine is assumed to be one-half the size of the basic engine introduced in
the QSS TB (i.e. two cylinders of approximately 180 cc each). Its fuel consumption program map
therefore is scaled down accordingly (i.e., one-half the consumption at each point of the program
map pme / c m ).
With a suitable design, it is possible for series hybrid vehicles to have extremely low pollution emissions;
e.g. the California EZEV limits.
47
The electric generator is assumed to be twice the size of the one provided with the QSS-TB. Its
efficiency is assumed to remain the same.
The electric motor is scaled up by a factor of 3.5 (in both quadrants), which yields a maximum
torque level of 250 Nm and a maximum power output of approximately 37 kW. The efficiency
levels remain the same as those of the basic motor.
The electric motor is coupled to the wheel at a fixed gear ratio. The gear ratio selected of 3.5 allows
a top speed of around 150 km/h. Due to its large maximum torque at small rotating speeds, at low
speeds (up to around 60 km/h) the vehicle has rather good acceleration reserves.
The batteries can deliver approximately 9 kWh and are charged to about 30% capacity at the start. If
smaller batteries were to be installed, which would be possible considering the requirements of the
EU cycle, the result would be unacceptably high voltages6 during the acceleration phases at the end
of the cycle.
If we assume an energy density of 70 Wh/kg, which is a good value nowadays, a battery of around
130 kg would be required. Adding the electric power system, the two electric motors, etc. would add
a net weight of 200 kg (i.e., additional weight minus the weight savings due to a smaller IC engine
and drivetrain).
The controller is rather straightforward: The main goal is to run the vehicle in such a way that at the
end of an EU cycle the battery shows the same charge level as it did at the beginning (the so-called
"autarky" or self-sufficiency level). The charge period is designed to be during the high-load phase
near the end of the EU cycle.
The actual battery charge level serves as input to the controller which detects any drop below a
certain level. Whenever the controller is activated, it first increases the idle speed of the IC engine to
the maximum charging level and then gradually adds the electric generator torque. The deactivation
occurs equally gently.
Some of the results of the calculations described above are depicted in Figs. 3.1.2 through 3.1.5. As
mentioned earlier, the electric motor shows rather significant torque reserves, particularly at low rotating
speeds (see Fig. 3.1.2). However, the top speed cannot be raised much beyond the top of the one shown for
the EU cycle. These characteristics of the vehicle can be improved by changes in the transmission ratio or,
more simply, by using a two-gear gearbox system.
Of course, those voltages could be attenuated by electrical "peak shavers" such as the "supercaps"
described earlier.
48
250
1. 2
1. 4
200
1.3
15
1. 4
1.2
1. 3
150
1.
1. 1 1.3
5
100
1.3
1.1
1.3
1.15
1 0.8
0.85
0. 8
0.
1.2
0.8
1.15
1.2
1.1
0.85
11.15
0.85
0.8
0.8
1.15
1.2 1.21.1
1.1
1.3
5
0.85
0.8
0.7
TEM [Nm]
-50
1.2
0.7
1.4
0 11.3
1.15
0.85
0.8
1.2 1.
1. 2
1. 4
50
-100
0. 7
0.85
0.8
0.7
-150
0. 85
0.
0.8
0.7
-200
-250
0
100
200
300
400
500
600
EM [rad/s]
Fig. 3.1.2
Driving Cycle:
Parameter
Value
Choose a cycle
Europe NEDC
ON
Vehicle:
Parameter
Value
750+200
2.0
0.5
0.22
0.008
Transmission Vehicle-EM:
Parameter
Value
3.5
Efficiency [-]
0.98
300
Transmission CE-EG:
Parameter
Value
0.75
Efficiency [-]
0.98
200
49
Electric Motor:
Parameter
Value
3.5
0.1
Electric Generator:
Parameter
Value
Combustion Engine:
Parameter
Value
Engine type
Otto
Displacement [l]
0.708
0.5
0.05
105
OFF
Battery:
Parameter
Value
100
27.78
20
Tank:
Parameter
Value
Fuel
Gasoline
OFF
The battery variables during the EU cycle are shown in Fig. 3.1.3 a)d) below. Since the latter part of the
EU cycle is very demanding, Fig. 3.1.3.b) clearly shows the drop in battery voltage.
Fig. 3.1.4 shows the operating points of the generator from its start at idle (i.e., without torque or current
output) and then charged. The operating points are all found to be near its peak efficiency of at least 85%.
50
Battery voltage
0.28
160
150
0.27
UBT [V]
qBT [0-1]
140
0.26
130
120
0.25
110
0.24
500
1000
100
1500
500
Time [s]
Battery current
20
10
P BT [kW]
100
-100
0
-10
-20
500
1000
-30
1500
500
Time [s]
1000
1500
Time [s]
0.75
140
0.7
120
0. 8
0. 7
0.75
0.8
100
0.
83
0. 8
0.75
80
00. 7
. 85 0. 7
0.7
60
0. 83
0.
83
85
0. 8
40
0.
20
0. 7
0. 83
0. 8
0. 7
100
Fig. 3.1.4
0. 7
200
0 75
300
EG [rad/s]
05.08. 7
0. 83
TEG [Nm]
IBT [A]
1500
Battery power
200
-200
1000
Time [s]
400
0.8
0 75
500
600
51
The efficiency of an IC engine during the charging phase is shown as well. During acceleration, it runs up
only its inertia and that of the electric generator, but even those few peaks are within an acceptable
efficiency level of about 20%.
TCE [Nm]
0.3
30
0.275
20
0.2
10
0.1
0
100
200
300
400
500
600
700
800
CE [rad/s]
Fig. 3.1.5
A comparison between Figs. 3.1.4 and 3.1.5 clearly shows the torque reserves of the generator as opposed
to a nearly maximum torque of the IC engine when both are run at the maximum output of slightly over 20
kW at the rotating speed selected. If a higher output level of the range extender group was desired, a
different transmission ratio would have to be used which in turn would not be tolerable for the batteries
chosen. In real situations demanding higher outputs flowing from the generator to the electric motor, such
as in climbing for extended times, either a gear box would have to be included in the "range extender
group", or the output of the IC engine would have to be throttled.
52
3.2
New elements can be added easily if a few points are considered along the way. Using its inputs any new
element must recalculate its outputs once every cycle. As Simulink does not show the sequence in which it
recalculates the various blocks, it is important to ensure that these blocks do not contain any implicit
conditions whenever these outputs are recalculated.
If any "dynamic" elements are to be considered, such as those necessary for integrators, they should be
included in time-discrete "delay" blocks only. Within those blocks, their step size must be set to h , and
they may not be termed differently.
Implicit functions are allowed, but they usually cause noticeably longer computation times. Besides, the
Simulink solver may have trouble solving implicit equations due to the fact that they can represent
discontinuities within the model equations. It is thus preferable to solve any implicit equations prior to
adding those elements. If that cannot be done, the inclusion of a "delay" block may break up the implicit
loop (cf. the description of the battery model in Sec. 2.5.1 above).
Besides the fact that the general rules for Simulink programming and generally good programming
techniques should be followed, there is nothing new required for the addition of new elements.
53
3.3
One of the main strengths of the QSS TB is the ease with which all of the models developed can be
included in other Matlab programs, thus allowing to take advantage of the full range of functions that the
multitude of Matlab toolboxes offers. One example of such an inclusion in the Optimization Toolbox is
shown below (Sec. 3.4).
The "sim" instruction is the key to the inclusion of any QSS TB program. The model to be simulated may
be called up simply with the instruction:
>> sim('model_name');
where the single quote signs around the name of the model from the QSS TB to be simulated are a Matlab
rule. Simulink then refers to the model parameters defined within the Matlab workspace and to the initial
conditions and the simulation parameters (e.g., accuracy demanded, time to end, etc.) defined within the
QSS TB model to run the computation of the model. A number of control parameters as well as the desired
output may be changed at the time the model is called up since the instruction "sim" is a "regular" Simulink
instruction. The instructions "help sim" and "help simset" provide further details.
If the transmission of the results from Simulink to Matlab does not run smoothly, this may be due to the
distinctions Matlab makes among the areas where its variables are saved. There are two ways to avoid this
problem: Either the "sim" instruction is written to include specific instructions for the output, or so-called
"global" variables are introduced with the instruction "global".
Calling up the QSS TB is comparable to calling up any other Matlab function, except of course that the
CPU time of an entire cycle simulation is longer than that of a simple function. In any case, the full range
of possibilities Matlab offers in signal processing, the visualization of data, etc. can be used with this
toolbox.
54
3.4
The following optimization problem is to serve as an example for the embedding of a QSS program in a
Matlab routine:
How should a standard (manual) transmission be designed for optimum fuel consumption in the EU cycle?
Given that the vehicle under consideration must be able to drive the EU cycle, we want to find the gear
ratios that lead to the lowest fuel consumption possible under the conditions defined by the EU legislation
(the EU cycle prescribes which gear is to be engaged for all times in the cycle). Obviously, a more useful
problem would consider as additional parameters the time instances for the gear changes, etc., but it would
also be too complex for this brief example.
For this example, the vehicle, the engine, and all the other elements except for the gearbox system are those
considered in Sec. 1.3 above and in the lecture "Vehicle Engine Systems". Table 3.4.1 shows the initial and
the optimized gear ratios that resulted from these calculations.
Table 3.4.1
Original values
Optimized values
i1 = 15.7140
i2 = 8.3380
i3 = 5.3780
i4 = 3.9370
i5 = 2.7480
i1 = 15.534
i2 = 10.597
i3 = 2.7029
i4 = 2.5746
i5 = 2.4089
The resulting fuel savings are approximately 0.323 liters per 100 km which, based on the initial
consumption values of 3.457 l/100 km, indicate an improvement of slightly over 9%. As expected, the
concomitant changes in torque and rotating speed are shown in Fig. 3.4.1, i.e. torque increases, while speed
decreases somewhat. The drivability of a vehicle with these values would not likely to be acceptable since
it would have a relatively weak acceleration performance.
60
0.33
60
0.33
50
50
0.32
0.3
0.32
40
40
TCE [Nm]
TCE [Nm]
0.275
30
20
0.275
30
20
0.2
0.2
10
10
0.1
100
200
300
400
0.1
500
CE [rad/s]
Fig. 3.4.1
600
700
800
100
200
300
400
500
600
700
800
CE [rad/s]
55
The primary purpose of this optimization is to include the Simulink model, i.e., the QSS TB based thereon
which is used to compute the fuel consumption, as a subroutine in an existing optimization routine to
compute its optimization criterion.
This is a fully numerical optimization, which means that the gradients of the optimization criterion are not
available in a closed form. Instead, the optimization algorithm itself must numerically approximate the
gradients of the optimization criterion. For this example, the routine "fminsearch" from the Optimization
toolbox is used. Table 3.4.2 shows a relevant excerpt from its User's Guide.
Table 3.4.2
Excerpt from the help text concerning the optimization routine used
(where i_1g i_5g are the guessed values of the gear ratios that have to be entered by
the user prior to starting the optimization) and:
i_opt = fminsearch('OptiGear',i_guess).
Table 3.4.3 shows the computation of the optimization criterion within OptigGear.
The routine OptiGear receives the actual value for the gear ratio in the vector gear_result.
Any additional parameters that are subject to being treated or changed must be predefined as global (a
procedure copied from the "common" structure of the FORTRAN programming language).
The computation itself, i.e., the quasistatic simulation of the vehicle model, is started by the
instruction sim. In the simplest case in which all starting conditions, end time, etc. are given within the
QSS program, sim only requires the name of the Simulink file to be run.
The output of the subroutine OptiGear represents the total fuel consumption of the cycle.
In case the cycle is not computed all the way through, i.e., the actual number of computation steps required
to complete the cycle is less than the given value N_sim, the computation yields a high consumption
value by design to ensure that the constraints are duly considered. However, this is possible only if the
Simulink program proper also contains the mechanisms necessary to recognize overload and overspeed
situations and to react with a simulation abort, if necessary. The QSS TB elements of course do fulfill these
conditions.
56
Additionally, a plausibility check to ensure that the computed gear ratios are sorted (in the sense that the
inequality first gear > second gear > third gear > fourth gear > fifth gear holds) is done; if the above
mentioned inequality is not satisfied, by design the computation yields too high a consumption value.
Table 3.4.3
t
N_sim
w_CE T_CE
gear_result
V_liter
first_gear second_gear third_gear fourth_gear fifth_gear
In order to allow the optimization routine to communicate with the .mdl file and to run the simulation
with the actual computed gear ratio values, the mask of the Manual Gear Box block (see Fig. 2.4.6) has
to be slightly modified by entering the variable names as depicted in Fig. 3.4.2.
The variables first gear fifth gear are computed at each computation step by the optimization
routine (see Table 3.4.3) and then, in accordance with the modifications of Fig. 3.4.2, sent to the .mdl file
in order to run the simulation.
57
Fig. 3.4.2
The modified entries for the mask of the Manual Gear Box block
The various gear ratios computed during the course of the optimization routine are shown in Fig. 3.4.3. The
optimization process reaches a static state after approximately 900 iterations; the concomitant fuel
consumption value of around 3.134 l/100 km should be near a local minimum as well.
One of the most interesting results of this simulation is that for the EU cycle a power train system requires
no more than three gears. The third, fourth, and fifth gears are so close together that their combination into
a single one does not significantly increase the consumption value: in fact, if the value for third gear is used
for the fourth and fifth gears as well, the resulting consumption value for the whole cycle is slightly higher
than the result obtained from the optimization algorithm (i.e., 3.134 vs. 3.171 l/100 km).
Variations of the gear ratios during the optimization
18
1. gear
16
14
12
2. gear
10
6
3. gear
4. gear
4
5. gear
2
Fig. 3.4.3
58
100
200
300
400
500
Iterations
600
700
800
900
1000
The various gear ratios computed during the course of the optimization routine
The QSS toolbox is a library of Matlab/Simulink block diagrams, analogous to the well known Simulink
Library included in each Matlab release. The user can imagine each element of a library like a pre-defined
object: to build a model it is simply necessary to drag the desired elements from the library to the
(blank) .mdl file. Then by double-clicking on each element it is possible to enter the desired corresponding
parameter values.
By default a library is locked, i.e. its elements cannot be customized without unlocking the library.
Therefore, before starting to customize the QSS TB library it is necessary to unlock it:
1.
2.
3.
Now the user is ready to effect the desired changes within the QSS TB library. As an example, the
Vehicle block is presented below.
Next, right-click on the block and choose Look Under Mask. The complete block diagram of the
Vehicle block (see Fig. 2.2.1) will appear.
59
Next, right-click on the block and choose Edit Mask. The Mask editor is started as follows:
60
First, the procedure to change the model parameters is shown. By clicking on the layer Parameters a user
interface to add, remove, or rename the parameters of the block will appear:
Add a new
parameter
Enter prompt
Remove
parameter
Move up
Move down
Obviously, the chosen variable names should be the same as in the Simulink block diagram!
Next, by clicking on the layer Initialization it is possible to enter the commands that the Vehicle block
needs prior to starting the complete simulation. In this case, all commands are saved in the m-file
init_vehicle. The file init_vehicle is located in the folder \Initialize as well as the others init-files
needed by all others QSS-TB blocks.
The file init_vehicle (as well as the others init-files) must be included in the Matlab path!
61
For example, when using the block Vehicle the user has to enter the value for the parameter Wheel
diameter [m] (d_wheel). The QSS TB, however, needs the wheel radius to perform its computations.
Therefore in the file init_vehicle one can find following code line:
r_wheel = d_wheel / 2;
Finally, the user can change the name of the mask and write his/her own mask description. This is done by
clicking on the layer Documentation and entering the desired entries in the corresponding spaces.
Additionally the user can write his/her own html help pages, for example to give other users further
information about the new customized version of the QSS TB library block Vehicle.
To create a reference between the customized html help file MyHelpFile.htm located at the Internet site
www.MyWebSite.com and the mask, simply write the following command in the Mask help:
eval('web http://www.MyWebSite.com/MyHelpFile.htm');
62
References
[1]
63