moskwa
TRANSCRIPT
SAE 950417
Automotive Engine Modeling forReal-Time Control Using
MATLA B/SIMULINK
Robert W. WeeksModular Systems
John J. MoskwaPowertrain Control Research Laboratory
University of Wisconsin-Madison
SAE 950417 Weeks & Moskwa 3/24/95 -1-
This paper was published and presented at the Society of Automotive Engineers1995 International Congress and Exposition, Detroit, MI.
For more information you can contact:
Phone: Internet:SAE (412) 776-4841Robert Weeks (847) 869-2023 [email protected]
http://www.simcar.comJohn Moskwa (608) 263-2423 [email protected]
ABSTRACT
The use of graphical dynamic system simulation softwareis becoming more popular as automotive engineers strive toreduce the time to develop new control systems. The use ofmodel-based control methods designed to meet future emissionand diagnostic regulations has also increased the need forvalidated engine models. A previously validated, nonlinear,mean-torque predictive engine model* is converted toMATLA B / SIMULINK † to illustrate the benefits of a graphicalsimulation environment. The model simulates a port-fuel-injected, spark-ignition engine and includes air, fuel and EGRdynamics in the intake manifold as well as the process delaysinherent in a four-stroke cycle engine. The engine model canbe used in five ways:
• As a nonreal-time engine model for testing engine controlalgorithms
• As a real-time engine model for hardware-in-the-looptesting
• As an embedded model within a control algorithm orobserver
• As a system model for evaluating engine sensor andactuator models
• As a subsystem in a powertrain or vehicle dynamics model
Although developed and validated for a specific engine,the model is generic enough to be used for a wide range ofspark-ignition engines. Modular programming techniquesreduce model complexity by dividing the engine and controlsystem into hierarchical subsystems.
* Developed under a contract from the Power Systems
Research Department of General Motors ResearchLaboratories.
† MATLAB and SIMULINK are trademarks of TheMathWorks, Inc.
INTRODUCTION
Dynamic system simulation software is an important toolfor developing reliable, low emission engine and powertraincontrol systems. Several companies market software (andhardware) that can be used to rapidly simulate a dynamicsystem and its controller using various combinations of PCand/or workstation technology.‡ Many of these companiesprovide software tools that allow development of libraries ofcomponent models. As these component model libraries aredeveloped, new control systems are easily simulated byreusing previously built subsystems.
In an effort to develop some of these reusable subsystemmodels, a previously validated mean torque predictive enginemodel was converted from FORTRAN to MATLAB /SIMULINK .§ The SIMULINK engine model is simulatedwithin a larger system model that also includes sensor, actuatorand engine controller subsystem models.
The paper begins with an overview of the engine andcontrol system model briefly describing the varioussubsystems. Additional detail is provided for the enginemodel’s intake manifold subsystem before a series of examplesimulations are examined. The example simulations illustratehow mean torque predictive models can be useful forpredicting a number of variables important to the controlsystem engineer. Execution times for the model are providedin the appendix.
‡ A partial list includes: The MathWorks, Inc., Integrated
Systems, Inc., dSPACE GmbH, Xanalog Corp. and VisualSolutions, Inc.
§ A complete theoretical review of the mean torquepredictive engine model is beyond the scope of this paper.Readers interested in a detailed development of the enginemodel should refer to [1,2,3].
SAE 950417 Weeks & Moskwa 3/24/95 -2-
Figure 1: Root level of the SIMULINK engine and control system model
ENGINE AND CONTROL SYSTEM MODELS
This section briefly describes the uppermost (or “root”)level of the engine and control system model shown in Fig. 1.This level of the model is displayed when the file “engsim.m”is loaded into SIMULINK . The SIMULINK graphical blockdiagram language allows models to be written in a modular,hierarchical format. The overall system model in Fig. 1simulates an engine and control system consisting of anengine, engine sensors and actuators and an engine controller.Inputs to the engine include: throttle angle, an external loadtorque such as that due to a dynamometer or a transmission,ambient conditions (i.e., atmospheric temperature andpressure) and actuator inputs from various “actuators” such asfuel injectors, EGR valve, etc. All the important enginevariables are “vectored” and made available to othersubsystems such as Sensors, Actuators and Data Analysis.Before a simulation is run the Load Vehicle Specific Datablock must be double-clicked with a mouse. This executes anm-file script which loads all of the vehicle specific parametersinto MATLAB ’s workspace memory. By separating vehiclespecific data from the subsystem models, the models are moregeneric, allowing development of one model that simulatesseveral engines.
EngineThe inside of the Engine block (from Fig. 1) is shown
below in Fig. 2. This block “demuxes” all the engine’s inputsand routes them into the Mean Torque SFI Engine block.The Mean Torque SFI Engine block contains a SIMULINKversion of the engine model described in [1]. All theimportant variables from the engine model are routed into theEngine Variable Connector where they are “muxed” into avector* called Engine Variables.
mdot_fi
3alpha
2Tload
1Ambient
Conditions
Pin
Tin
4ActuatorOutputs
Demux
Demux
spark_advance
inj_pw_deg
mdot_IAC
mdot_egri
Demux
Demux1
Mean Torque SFI Engine
EngineVariable
Connector1
EngineVariables
Figure 2: Engine block (from Fig. 1)
* Vectors in SIMULINK 1.3 are normally shown as thicklines in block diagrams.
SAE 950417 Weeks & Moskwa 3/24/95 -3-
SensorsThe Sensors block visible in Fig. 1 contains all the engine
sensor models (shown in Fig. 3). A subset of the enginevariables are routed into individual sensor models. Eachsensor may be modeled to the degree of accuracy necessary fora given simulation.
7out_7
8out_8
4out_4
5out_5
3out_3
6out_6
2out_2
1out_1
8in_8
7in_7
6in_6
5in_5
4in_4
3in_3
2in_2
1in_1
double-click to plotsensor tables
Engine SpeedSensor
Ambient AirTemperature Sensor
Manifold AbsoluteTemperature Sensor
Air MassSensor
Baro Sensor
Manifold AbsolutePressure Sensor
Throttle PositionSensor
Exhaust GasOxygen Sensor
Figure 3: Sensors block (from Fig. 1)
ControllerThe contents of the Controller block shown in Fig. 1 are
shown below in Fig. 4. Discrete time control algorithms areplaced inside the Control Algorithms block which is “wired”between the input and output signal conditioning blocks. TheInput Signal Conditioning block performs the conditioningnecessary to convert the simulated sensor outputs to theengineering units typically used by the Control Algorithmsblock. This often involves analog-to-digital converter modelsand conversion tables. The Output Signal Conditioningblock converts control signals to the type of signal necessaryfor the engine’s control actuators, such as a pulse widthmodulated signal, a desired stepper motor position, etc.
1SensorOutputs
ControllerVariables
DigitizedInputs
Input SignalConditioning
ControlAlgorithms
Output SignalConditioning
1Actuator
Inputs
2ControllerVariables
Figure 4: Controller block (from Fig. 1)
ActuatorsThe contents of the Actuators block (from Fig. 1) are
shown below in Fig. 5. Four actuators are used for this enginecontrol system, including fuel injectors, an ignition system, anexhaust gas recirculation valve and an idle air control valve.The actuator commands (from the controller) come in throughinport 1. A Signal Select block was created to split theactuator signal vector (or “harness”) and route the signals tothe appropriate actuator models. Each of the actuators has amass flow rate for its output, except for the Ignition Systemblock where the output is simply a value for the current sparkadvance. The Fuel Injectors block also determines theinjector pulse width in degrees of crank rotation. This is usedin the engine model to determine if a portion of the fuel pulse
is injected after the intake valve closes (and thus goes throughan additional delay before entering the cylinder).
IAC_cmdmdot_IACIAC
Valve
EGRValve
Ignition System
Fuel Injectors
mdot_fi
inj_pw_deg
spark_adv
double-click to plotactuator tables
2Engine
Variables
SA_cmd
mdot_fi_cmd
EGRvalve_cmd
Mux
Mux
1
mdot_egri
Signal Select(using mux)1
Actuatorcommands
Figure 5: Actuators block (from Fig. 1)
The mass flow rates through the EGR and IAC valves areaffected by the stagnation conditions upstream of the valves aswell as the pressure drop across the valves. These two valvemodels are therefore connected to the Engine Variablesvector allowing access to the appropriate pressures andtemperatures from the engine model. Separating the actuatormodels from the engine model allows revisions (orsubstitutions) of the actuator models without updating theengine model. This type of modularity makes the enginemodel more generic.
Data AnalysisThe contents of the Data Analysis block (from Fig. 1) are
shown below in Fig. 6. This block is used strictly for storingdata to the MATLAB workspace (or to disk) as well as forvisualizing variables during a simulation run (typically withSIMULINK scope blocks). The Data Analysis block can beremoved from the overall control system model withoutaffecting the simulation. It simply provides a convenientmethod for comparing variables in the engine to variables inthe controller. Engine and controller variable vectors are“demuxed” in the Data Analysis block to make it easy toselect arbitrary combinations of variables for visualizationduring a simulation run.
1ControllerVariables
14 mdot_throt
Demux
Demux1
20 Texh
3 AFport
23 torq_fric_pump
22 torq_indicated
21 Tman
19 Tcool
18 Tamb
17 Pman
16 Pexh
15 Pamb
13 mdot_IAC
12 mdot_fo
11 mdot_fi
10 mdot_egro
9 mdot_egri
8 mdot_ao7 mdot_ai
6 EngSpeed
5 EGRfrac
4 alpha
2 AFexh
1 AFego
Demux
Demux
2Engine
Variables
Tman_m 25
Tamb_m 14
SA_cmd 13
IAC_cmd 7
EGRvalve1_cmd 5
EGRvalve2_cmd 4
alpha_m 2
AFego_m 1
EngSpeed_m 6
EGRvalve3_cmd 3
mdot_fi_cmd 10
Pamb_m 11
Pman_m 12
mdot_AMS_m 8
mdot_ao_est 9
display throttleflow rates
displaypressures
Save Results
display portflow rates
Figure 6: Data Analysis block (from Fig. 1)
SAE 950417 Weeks & Moskwa 3/24/95 -4-
MEAN TORQUE SFI ENGINE MODEL
The Engine block briefly described in the previoussection is more thoroughly described in this section. Theengine model is physically based and captures the majordynamics (lags and delays) inherent in the spark ignitiontorque production process. It is a continuous time delay, meantorque-predictive model designed primarily for the controlengineer. It does not attempt to predict flow and torquepulsations due to individual cylinder filling events. The enginemodel was derived from the four state, lumped parameterdynamic engine model developed in [1].
The Mean Torque SFI Engine block (from Fig. 2) isshown below in Fig. 7. This block consists of four subsystemblocks: the Throttle Body, the Intake Manifold , the EngineBlock and the Exhaust Manifold.
mdot_ai 7
mdot_throt14
11
Mux
Mux
5mdot_fi
6inj_pw_deg
Throttle Body
13
18
15
4
2Tamb
1Pamb
4alpha
9mdot_IAC
98
mdot_egri
2
EngSpeed
torq_indicated
Texh
Tcool
AFexh
16
1AFego
Pexh
6
20
19
22
torq_fric_pump
ExhaustManifold
23
EngineBlock
7spark_adv
3Tload
10
5
3
12
8
21
17
mdot_egro
EGRfrac
AFport
mdot_fo
mdot_ao
Tman
Pman
IntakeManifold
double-click to plotengine specific tables
Figure 7: Mean Torque SFI Engine block (from Fig. 2)
The Throttle Body block calculates the total mass flowrate of air entering the intake manifold (mdot_ai). One-dimensional isentropic compressible flow equations determinethe throttle flow rate (mdot_throt) as a function of throttleangle (alpha), intake manifold pressure (Pman), and upstreamstagnation conditions (Pamb and Tamb). The total flow rateinto the manifold is simply the sum of the throttle flow rate,the idle air control valve flow rate, and the flow due to anyintake manifold leaks as shown below in Fig. 8. The throttleflow rate calculations used in the throttle body model havealso proven useful in engine controllers for constructing“observers” that estimate the transient air flow rate at thethrottle and intake ports of an engine [4].
P and T Correction
*
Product
*
Product1Vacuum LeakFlow
+++
Sum
1mdot_ai
4Tamb
2mdot_throt
mdot_leak
2alpha Throttle Flow
5mdot_IAC
-K-
LeakSize
divide
1Pman
3Pamb
PR
RepeatingSequence
Figure 8: Throttle Body block (from Fig. 7)
The Intake Manifold block’s main purpose is todetermine the manifold pressure as well as the mean-valuemass flow rates of air, fuel and EGR in the intake ports of theengine. A more complete description is given in the IntakeManifold subsection that follows.
The Engine Block’s main purpose is to perform thetorque production and rotational dynamics calculations.Double clicking two levels down into the Engine Block blockreveals the Torque Production block shown below in Fig. 9.The Torque Production block calculates the indicated torque(torq_indicated) and subtracts off the friction and pumpingtorque of the engine (torq_fric_pump) to get the brake torque(torq_brake). Any external load torques are then subtractedfrom the brake torque to determine the net torque whichaccelerates or decelerates the crankshaft. The crankshaftacceleration is then integrated to get the engine speed(EngSpeed).
1/sIntegrator
Friction andPumping
Torque (tbl)
EngLoad
1torq_indicated
2torq_fric_pump
5Load torque
torq_brake
3EngSpeed
-K-
1/Je
+
-
Net torque
-
+
Sum
CalculateIndicated Torque
2Pman
1EGRfrac
6spark_adv
4AFport
3mdot_ao
Figure 9: Torque Production block
Intake ManifoldThe Intake Manifold block (mentioned earlier in the
MEAN TORQUE SFI ENGINE MODEL section) is morethoroughly examined in this subsection to lay the groundworkfor a parametric study presented later in the EXAMPLESIMULATIONS section of the paper. The contents of theIntake Manifold block from Fig. 7 are shown below in Fig.10. The intake manifold has three dynamic subsystems: air,fuel and EGR. The Air Dynamics block calculates a port flowrate which assumes a homogeneous mixture of air and EGR.The port EGR flow rate (mdot_egro) is then subtracted fromthe total port flow rate (air + EGR) to determine the port airflow rate (mdot_ao). The port fuel flow rate (mdot_fo) isassumed to not interact with the air or EGR dynamics.* Anintake port air/fuel ratio is calculated by simply dividing theport air flow rate by the port fuel flow rate.
1Pman
+-
Sum
EGRDynamics
AirDynamics
4mdot_fo
3mdot_ao
EGRfraction
6EGRfrac
divide5
AFport
7mdot_egro
1mdot_ai
TmanTman
2
3mdot_egri
4EngSpeed
FuelDynamics
2mdot_fi andinj_pw_deg
VE
Figure 10: Intake Manifold block (from Fig. 7)
* On gasoline engines the partial pressure of fuel vapor in
the intake manifold can generally be ignored in regards to itsaffect on air or EGR flow.
SAE 950417 Weeks & Moskwa 3/24/95 -5-
Air DynamicsThe contents of the Air Dynamics block from Fig. 10 are
shown below in Fig. 11. The Manifold filling dynamicsblock (from Fig. 11) calculates the intake manifold pressure(Pman) using a block diagram version of Eq. 1 [1]:
d
dtP
T
TC P
R T
Vm mman
man
mane vol man
man
man
ai egri= − ⋅ ⋅F
HGG
I
KJJ ⋅ + ⋅ ⋅ +F
HIK
•• •
1 ω η . (1)
The Port flow rate block in Fig. 11 determines the total portflow rate using a speed-density calculation. The modelassumes air and EGR are homogeneously mixed and have thesame molecular weight and temperature. With thissimplification it is possible to estimate the combined massflow rate of air and EGR entering the cylinders using atraditional speed-density calculation. In practice, it is difficultto determine the percentage of the combined flow rate due toair flow alone (mdot_ao). In the model this value is calculatedby subtracting the EGR flow (mdot_egro) from the combinedflow (see Fig. 10).
2Pman
1Total portflow rate
3VE
2mdot_ai
4mdot_egri
3EngSpeed
1Tman
Manifold fillingdynamics
Portflow rate
Figure 11: Air Dynamics block (from Fig. 10)
Fuel DynamicsThe contents of the Fuel Dynamics block visible in Fig.
10 are shown below in Fig. 12. The calculations performed inthe Fuel Dynamics block are based on Eqs. 2-6 below [1,3]. Afraction of the mean injector flow rate (shown as mdot_fi inFig. 12), goes through one or two pure time delays as well as afirst order lag before it finally enters the cylinders as mdot_fo.The pure time delay, t T− ∆ 1b g , represents the average delay
from a change in the fuel command to the actual start ofinjection (SOI) plus the delay from the start of injection untilthe intake valve closes (IVC). This delay is performed by thefuel delay (delta t1) block in Fig. 12. The delay, t T− ∆ 2b g ,represents a two revolution delay for any fuel injected after theintake valve closes (see the 2 rev delay (delta t2) block inFig. 12).
epsilon and tauf are shown as constants here but in generalare time varying functions of speed, load, temperature, etc.
if intake valve closes while fuel is injectedthen some fuel gets delayed two revs
2EngSpeed
2 rev delay(delta t2)
fuel delay(delta t1) gamma -
+Sum1
slow fuel
mdot_fs1
taufslow fuel
time constant
epsilonfuel split
1mdot_fi
andinj_pw_deg
*Product1
fast fuel
+-
SumTime varying
Lag filter
Slow fuel lag
mdot_ff2
*Product
1mdot_fo
+++
Sum2
mdot_ff3
Figure 12: Fuel Dynamics block (from Fig. 10)
The fuel split parameter, ε , is the fraction of the injectedfuel with transport properties of a gaseous fuel. It is called“epsilon” in Fig. 12. The slow fuel time constant, τ f , is the
first order lag filter time constant applied to the fraction of theinjected fuel with transport properties of a liquid fuel. It iscalled “tauf” in Fig. 12. The variable, γ , is the fraction of thefuel injected before the intake valve closes. It is calculatedand output from the gamma block in Fig. 12. The values of“epsilon” and “tauf” are shown as constants in Fig. 12, but ingeneral are time varying as a function of manifold temperature,pressure and engine speed. A table of values could easily besubstituted for the constants in Fig. 12.
m m m mfo ff ff fs
• • • •= + +2 3 1 (2)
where:
m mff fi
t Tt T
• •
− −
= ⋅ ⋅ −L
NM
O
QP2
12
1∆ ∆b g
b g
b gε γ (3)
m mff fi
t T
• •
−= ⋅ ⋅3
1∆b g
ε γ (4)
d
dtm
m m
fs
fi
t T
fs
f
•
•
−
•
FH
IK =
⋅ − −1
1
1
1∆b g
a fε
τ (5)
γ =≤
>
R
S|
T|
1, if -
-, if -
Φ Φ ΦΦ Φ
ΦΦ Φ Φ
PW IVC SOI
IVC SOI
PWPW IVC SOI
(6)
ENGINE SPECIFIC TABLES
Before an engine simulation is run, the MATLABworkspace memory must be loaded with all the parameters thatare specific to a particular engine. This is usually done bydouble-clicking on the Load Vehicle Specific Data block inFig. 1 but can also be done by just typing “simspec” at theMATLAB prompt. Both methods run an m-file script called“simspec.m”. This m-file actually executes a number of otherm-files which all contain data specific to one or more of thesubsystem models. A partial listing of simspec.m follows:
SAE 950417 Weeks & Moskwa 3/24/95 -6-
...
% load ambient conditions
ambspec
% load engine specs and initialization values
engspec
% load sensor specs
sensspec
% load controller specs
ctrlspec
% load actuator specs
actspec
% load disturbance specs (noise, leaks, etc.)
distspec
...
Each of the commands above executes a script file; forexample “ambspec” executes the script file ambspec.m whichinitializes the variables used for ambient temperature andpressure. Tables are used for many of the engine specificparameters even if an analytical expression could have easilybeen embedded in the SIMULINK model.* Tables make themodel more generic because they have more degrees offreedom than an analytical expression or regression equation.In some cases tables are initialized using regression equations.This gives additional flexibility without the need to embedengine specific equations in the SIMULINK model.
In addition to initializing a number of engine specificconstants such as engine displacement (Veng) and intakemanifold volume (Vman), the m-file engspec.m loads nineengine specific tables of the following parameters:
• Throttle characteristic vs. throttle angle• Pressure ratio influence vs. pressure ratio• Volumetric efficiency vs. engine speed and manifold
pressure• MBT spark vs. engine speed and load• Air/fuel ratio influence vs. air/fuel ratio• Spark influence vs. spark advance relative to MBT• EGR correction to MBT vs. EGR fraction• Fuel conversion efficiency vs. engine speed and manifold
pressure• Friction and pumping torque vs. engine speed and load
The m-file actspec.m loads three more tables specific tothe engine actuators:
• Fuel flowrate vs. injector pulse width• EGR flow calibration vs. EGR valve position• IAC flow calibration vs. IAC valve position
The overall accuracy of the engine model depends to alarge extent on the number of the above tables calibrated torepresent the engine of interest. The model was originallyvalidated using a naturally aspirated, sequential port fuelinjected, 3.8L V6 gasoline engine. Similar engines may be
* SIMULINK has built-in blocks for performing table look-
ups that interpolate between table values.
simulated with reasonable accuracy without the need torecalibrate all of the above tables.
EXAMPLE SIMULATIONS
Several simulations were run to demonstrate the output ofthe engine and control system model. Unless otherwisespecified the following simulation parameters were used:
• Engine displacement (Veng)=3.8L• Intake manifold volume (Vman)=3.4L• Fuel split parameter (epsilon)=0.53 (unitless)• Slow fuel time constant (tauf)=0.22 seconds• Discrete controller time step (deltaT)=0.005 seconds• Air-mass sensor time constant (AMStau)=0.005 seconds• Analog to Digital Converter (ADC) resolution=8 bits (except for a 10 bit throttle angle measurement)• Noise on ADC inputs=± 1
2 bit• Start of injection to intake valve close angle
(SOItoIVC_deg)=312 crank degrees
The throttle trajectory used for the example simulations isshown in Fig. 13. After one second the throttle is ramped from5 to 20 degrees at a rate of 900 degrees/second. At the twosecond simulation time the throttle is ramped back to 5degrees. No external load torques are applied to the engine, sothe simulation approximates a free-revving engine’s responseto a rapid throttle transient.
0 1 2 3 4 50
10
20
30
40
50
60
70
80
Time (sec)
Thr
ottle
Ang
le (
degr
ees)
Figure 13: Throttle trajectory for example simulations
Baseline using Air Mass SensorFigures 14-19 illustrate the output of the engine and
control system model when an air mass sensor is used by thecontroller to calculate a fuel command. Throttle and intakeport air flow rates (mdot_ai and mdot_ao, respectively) areillustrated in Fig. 14. Note that a small manifold filling spikeappears in the throttle flow rate as the throttle is opened.
SAE 950417 Weeks & Moskwa 3/24/95 -7-
ThrottlePort
0.5 1 1.5 2 2.5 30
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08A
ir flo
w r
ate
(kg/
s)
Time (sec)
Figure 14: Throttle and intake port air flow rates
Injector flow rate (mdot_fi) and intake port fuel flow rate(mdot_fo) are both shown in Fig. 15. The granularity of theinjector flow rate is due to the 8 bit analog to digital converterused to “measure” the air mass sensor as well as ± 1
2 bit ofnoise included in the ADC model. The lag in the intake portflow rate is due to the fuel dynamics, described earlier.
Injector Intake Port
0.5 1 1.5 2 2.5 30
1
2
3
4
5x 10
-3
Fue
l flo
w r
ate
(kg/
s)
Time (sec)
Figure 15: Injector and intake port fuel flow rates using an air-mass sensor fuel calculation
The air/fuel excursions in Fig. 16 show that the lags due tofuel dynamics are not canceled by the lead informationprovided by the air mass sensor. The combination of the twostill results in a lean excursion due to throttle openings and arich excursion when the throttle closes.*
* On some port fuel injected engines with large intake
manifolds it is possible for the lead information from the airmass sensor to cause a rich excursion on throttle openings.
0.5 1 1.5 2 2.5 30
10
20
30
40
50
Inta
ke P
ort
A/F
Time (sec)
Figure 16: Intake port air/fuel ratio using an air-mass sensorfuel calculation
Intake and exhaust manifold absolute pressures are shownin Fig. 17. The intake manifold pressure drops below 53 kPaas the simulation time exceeds 1.25 seconds. This causes theflow rate at the throttle to choke and thus not increase even asengine speed rises.
Intake Exhaust
0.5 1 1.5 2 2.5 30
50
100
150M
anifo
ld p
ress
ure
(kP
a)
Time (sec)
Figure 17: Intake and exhaust manifold absolute pressures
The engine’s indicated torque is plotted in Fig. 18 alongwith the value of its friction and pumping torque. The initialthrottle tip-in causes an air/fuel excursion lean enough to resultin a “misfire” where indicated torque momentarily drops tozero. As engine speed increases, the internal friction andpumping torque of the engine approaches the value of theindicated torque causing engine speed to level off becausethere is no net torque available to continue accelerating thecrankshaft.
SAE 950417 Weeks & Moskwa 3/24/95 -8-
Indicated Friction/Pumping
0.5 1 1.5 2 2.5 30
20
40
60
80
100
120
140
160T
orqu
e (N
*m)
Time (sec)
Figure 18: Engine indicated and friction/pumping torqueusing an air-mass sensor fuel calculation
The engine speed quickly accelerates from about 2500RPM to nearly 6500 RPM during the throttle trajectorybecause there is no load on the crankshaft. This is illustratedin Fig. 19 below. A very slight drop in engine speed isobserved at the start of the throttle tip-in due to the momentarydrop in indicated torque.
0.5 1 1.5 2 2.5 3200
300
400
500
600
700
Eng
ine
Spe
ed (
rad/
s)
Time (sec)
Figure 19: Engine speed using an air-mass sensor fuelcalculation
Baseline using Speed-densityThis subsection illustrates some of the differences in
engine performance when a speed-density calculation in thecontroller model determines the fuel command. In the baselinesimulations, no additional acceleration enrichment ordeceleration enleanment algorithms are tested. The speed-density fuel rates comparable to those in Fig. 15 are shownbelow in Fig. 20. The fuel flow rate does not rise as quickly asit did in the air-mass sensor baseline condition. This causeseven larger air/fuel excursions than the air-mass sensorbaseline (as evident in Fig. 21). In both sets of baselinesimulations the throttle tip-in causes a relatively large leanspike in the intake port air/fuel ratio. This is primarily due tothe pure time delays in the fuel dynamics portion of the engine
model. In the air-mass sensor baseline, the rapid rise in the airflow rate measurement (as compared to speed-density)improves transient fueling even though a speed-density systemis theoretically better matched to a port-fuel-injection engine[4].
Injector Intake Port
0.5 1 1.5 2 2.5 30
1
2
3
4
5x 10
-3
Fue
l flo
w r
ate
(kg/
s)
Time (sec)
Figure 20: Injector and intake port fuel flow rates using aspeed-density fuel calculation
0.5 1 1.5 2 2.5 30
10
20
30
40
50
Inta
ke P
ort
A/F
Time (sec)
Figure 21: Intake port air/fuel ratio using a speed-density fuelcalculation
The larger lean air/fuel excursion for the speed-densitybaseline causes a significant drop in indicated torque after thethrottle tip-in (as shown in Fig. 22). The longer duration dropin torque is caused by more cylinders misfiring due to the leancondition (as compared to the air mass sensor baseline),causing a noticeable drop in engine speed (see Fig. 23). Thedrop in speed would probably be felt as a “stumble” if theengine were running in a vehicle.
SAE 950417 Weeks & Moskwa 3/24/95 -9-
Indicated Friction/Pumping
0.5 1 1.5 2 2.5 30
20
40
60
80
100
120
140
160T
orqu
e (N
*m)
Time (sec)
Figure 22: Engine indicated and friction/pumping torque usinga speed-density fuel calculation
0.5 1 1.5 2 2.5 3200
300
400
500
600
700
Eng
ine
Spe
ed (
rad/
s)
Time (sec)
Figure 23: Engine speed using a speed-density fuelcalculation (note tip-in “stumble”)
Fuel Dynamics Parametric StudyOne of the advantages of using SIMULINK is that models
can be developed and run interactively using a graphicalinterface and also run from the MATLAB command line. Thismakes it easier to perform parametric analyses to examine theeffects of varying different constants in the model. With thehelp of optimization tools the model parameters can often beautomatically “tuned” to minimize a “cost” function and thusmaximize some user-defined performance criteria. It issometimes possible to “fit” the model to measured engine databy using commercially available optimization algorithms toautomatically adjust model parameters.*
This subsection demonstrates how the engine model maybe used in a simple fuel dynamics parametric study todetermine the effects of varying some of the fuel parametersmentioned earlier. The first parameter varied is the start ofinjection to intake valve closing angle (SOItoIVC_deg).
* The Levenberg-Marquardt method was originally usedto identify the dynamic fuel parameters for this model fromengine data on a dynamometer [3].
SOItoIVC_deg represents the number of degrees thecrankshaft rotates from when the fuel injector is opened towhen the intake valve (for that injector’s cylinder) closes.Most sequential port fuel injection systems control the timingof the injection relative to the intake valve opening so there isan interest in understanding how this affects air/fuel ratiocontrol and emissions.
There is a transient fueling advantage for waiting until theintake valve nearly closes before injecting a given cylinder’sfuel, but if the injector is still open after the valve closes, partof the fuel will have to wait in the intake port for nearly tworevolutions until the valve opens again. This contributes totransient air/fuel ratio errors.
There is often a steady-state fueling advantage to injectingfuel after the intake valve closes so it has the longest possibleresidence time in the intake port. This allows more time forthe fuel to vaporize in the vicinity of a hot intake valve and cansometimes lower steady-state emission levels.
The two strategies are diametrically opposed to oneanother making it difficult to determine the best time to injectfuel relative to the intake valve closing. The engine andcontrol system model can be used to help evaluate fuelingstrategies related to transient air/fuel control and how it isaffected by injection timing. The following MATLAB scriptfile shows how the engine and control system model shown inFig. 1 can be executed within a loop to determine the effect ofvarying SOItoIVC_deg:
clear % clear the workspace before starting
% define some global variables
global SOItoIVC_deg aferror x0 options
% load vehicle specific data into workspace
simspec
load initcond; % get initial conditions for states
% set fuel calculation flag
UseAMS=0; % 1=air-mass sensor, 0=speed-density
options=[1e-8,0.0001,0.001]; % set simulation options
for i=0:3
% initialize fuel injection parameter
SOItoIVC_deg=240*i;
% create a filename to store simulation results
filename=['SOI',int2str(i),'.mat'];
% simulate the engine and control system model
[t,x,yo]=rk45('engsim',[0.0,3.0],x0,options);
% save the results for later analysis
eval(['save ',filename,' y aferror']);
end
The above script file performs four separate simulationsof the engine and control system model (engsim.m) using aRunge-Kutta integration algorithm. SOItoIVC_deg is variedfrom 0 degrees up to 720 degrees in 240 degree increments.The results of each simulation are stored in a different file asfollows:
SAE 950417 Weeks & Moskwa 3/24/95 -10-
Another m-file was written to load the results and plot theintake port air/fuel ratio versus simulation time (shown in Fig.24). In the first run the fuel is injected right as the intake valvecloses where it would remain in the port for nearly tworevolutions before the valve reopens. During the throttletransient the air flow rate changes significantly during tworevolutions of the crankshaft. This effect contributes asubstantial portion of the air/fuel ratio error shown in the firstrun. In the second run (where SOItoIVC_deg=240) the fuelinjection is completed at about the same time as the intakevalve closing. This helps to minimize the transient air/fuelerrors but does not allow the fuel as much time to vaporize inthe intake port. The third and fourth runs show that when fuelis injected a significant time before the intake valve closes thetransient air/fuel errors will again increase. To help minimizethese transient air/fuel ratio errors, some injection strategiescontrol the end of injection relative to intake valve closurerather than the start of injection.
Previous steady state engine testing has shown thatinjection of fuel while the intake valve is open can lead toincreased emissions (due to poor vaporization and exhaustbackflow effects) but injection of fuel while the valve is closedcan lead to transient air/fuel ratio errors (which also leads toincreased emissions). An ideal strategy would be one that
could predict the air flow rate at the ports approximately twocrankshaft revolutions in the future and then inject the properfuel pulse (allowing for fuel dynamics) right after the intakevalve closes. This would allow the most time for fuelvaporization but would not suffer from transient air/fuel errorsdue to injection timing. An accurate prediction of future portair flow rates would require a drive-by-wire throttle so theengine controller could know the throttle’s trajectory over thenext two crankshaft revolutions. Then using an embeddedintake manifold model (similar to the one described in thispaper), the controller would predict future port air flow ratesas part of its fuel calculation. This is one of the authors’current research topics and is more thoroughly described in[4].
Fig. 24 illustrates a set of parametric runs showing theeffects of varying SOItoIVC_deg. A similar set of parametricruns were performed where the values used for the fuel splitparameter (epsilon) and the slow fuel time constant (tauf) werevaried. These results are shown in Figs. 25 and 26. As epsilonapproaches a value of one (see fourth plot in Fig. 25) the liquidfuel dynamics become negligible and most of the air/fuel erroris due to the pure time delay, ∆ T1 (see subsection on fueldynamics). A similar effect occurs as the slow fuel timeconstant (tauf) approaches zero (shown in the first plot in Fig.26).
The example simulations and the parametric studypresented here illustrate some of the possible uses of the meantorque predictive engine model. Other uses of the model aredescribed (but not illustrated) in the SUMMARY andCONCLUSIONS section.
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
SO ItoIVC_deg= 0
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
SO ItoIVC_deg=240
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
SO ItoIVC_deg=480
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
SO ItoIVC_deg=720
Time (sec)
Figure 24: Effects of varying start of injection relative to intake valve closing
file name test conditionSOI0.mat SOItoIVC_deg=0SOI1.mat SOItoIVC_deg=240SOI2.mat SOItoIVC_deg=480SOI3.mat SOItoIVC_deg=720
SAE 950417 Weeks & Moskwa 3/24/95 -11-
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
epsilon=0.00
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
epsilon=0.33
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
epsilon=0.66
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
epsilon=1.00
Time (sec)
Figure 25: Effects of varying fuel split parameter, epsilon
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
tauf=0.001
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
tauf=0.11
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
tauf=0.22
0.5 1 1.5 2 2.5 30
50
A/F
ra
tio
tauf=0.33
Time (sec)
Figure 26: Effects of varying slow fuel time constant, tauf
SAE 950417 Weeks & Moskwa 3/24/95 -12-
SUMMARY and CONCLUSIONS
An automotive engine model designed for real-timecontrol applications has been presented in the context of aSIMULINK engine and control system model. Subsystemswithin the model were briefly described with some additionaldetail related to the air and fuel dynamics portion of the intakemanifold subsystem. Example simulations were presented toshow some of the potential uses of the model.
In general, the model may be used in five different ways:
1. As a nonreal-time engine model for testing enginecontrol algorithms. Nonreal-time testing allowsresearchers and engineers to develop new controlalgorithms without the hardware constraints andsoftware complexities of running in real-time.* Thisallows new ideas to be rapidly evaluated using highlevel languages such as graphical block diagrams or C.High precision floating point calculations can be usedon low cost computers to rapidly iterate algorithmdesigns until a robust control law is found. Algorithmscan often be evaluated in a matter of minutes or hours,whereas many conventional development systemsrequire days or weeks to test new ideas because controlalgorithms must be written in assembler and tested onan actual vehicle.
2. As a real-time engine model for hardware-in-the-loop testing. Many engine models do a good job ofsimulating the dynamic behavior of an engine but arenot designed to run in real-time. The engine modelpresented here, is physically based but relatively simpleand uses a large number of table look-ups to reduceexecution time. When converted to C (see appendix),the model may be executed on a variety of targetprocessors. With a relatively low cost processor andappropriate I/O, the model may be used to evaluate theperformance of actual engine sensors, controllers oractuators. For example, an actual engine controller(ECU) could be tested in a highly repeatable anddeterministic manner using off-the-shelf simulationhardware [7].
3. As an embedded model within a control algorithmor observer. As model-based controls become morepopular, simplified versions or subsystems of an enginemodel are often embedded into a real-time controlalgorithm [4-6,8-19]. The embedded model can predictengine variables that are difficult or impractical tomeasure. Observers or state estimators can also be usedfor diagnostic purposes, such as those mandated byOBDII.
4. As a system model for evaluating engine sensor andactuator models. Vehicle manufacturers will eventuallyrequire suppliers to provide models of the components
* Some examples of nonlinear sliding mode engine control
algorithms (tested on the original FORTRAN version of theengine model described in this paper) are given in [5,6]. Thealgorithms use coordinated throttle and spark advance controlto force the engine to track desired engine and transmissionspeed trajectories.
they sell so the manufacturer can do system simulationsbefore prototype vehicles are built. When used as asystem model, the engine and control system model canevaluate different sensor and actuator models. Themodular design allows new sensor and/or actuatormodels to be tested without modifying the enginemodel. This makes it easier for component suppliers toperform system simulations of their sensor or actuatormodels without having to develop their own enginemodels.
5. As a subsystem in a powertrain or vehicle dynamicsmodel. Mean torque predictive engine models are oftenincorporated into larger powertrain or vehicle dynamicsmodels [20-23]. In general, as the complexity and sizeof a system model increases, the complexity ofsubsystem models must be reduced. Because of theirrelatively simple nature, mean torque predictive enginemodels are often more appropriate for vehiclesimulations than models that predict individual cylinderfilling phenomena.
Simulations are used by a large number of control systemresearchers but there is very little standardization in the plantmodels used for developing control laws. This makes itdifficult to evaluate research showing the benefits of differentcontrol theories. A validated benchmark model makes it easierfor control engineers at the vehicle manufacturers to evaluatecontrol algorithms developed by researchers at variousacademic institutions. A benchmark model will allowcomparison of new control algorithms in a very direct andrepeatable manner. This will make it easier for vehiclemanufacturers to identify promising control theories andtechniques.
REFERENCES
[1] Moskwa, J.J., “Automotive Engine Modeling for Real-time Control,” Department of Mechanical Engineering,M.I.T., Ph.D. thesis, 1988.
[2] Moskwa, J.J. and Hedrick, J.K., “Modeling andValidation of Automotive Engines for ControlAlgorithm Development,” ASME J. of DynamicSystems, Measurement and Control, Vol. 114, No. 2,pp. 278-285, June 1992.
[3] Moskwa, J.J., “Estimation of Dynamic Fuel Parametersin Automotive Engines,” ASME J. of Dynamic Systems,Measurement and Control, December 1994.
[4] Weeks, R.W. and Moskwa, J.J., “Transient Air FlowRate Estimation in a Natural Gas Engine Using aNonlinear Observer,” SAE paper No. 940759, 1994.
[5] Moskwa, J.J., “Sliding Mode Control of AutomotiveEngines,” ASME J. of Dynamic Systems, Measurementand Control, Vol. 115, No. 4, pp. 687-693, December1993.
SAE 950417 Weeks & Moskwa 3/24/95 -13-
[6] Moskwa, J.J. and Hedrick, J.K., “Nonlinear Algorithmsfor Automotive Engine Control,” IEEE Control SystemsMagazine, Vol. 10, No. 3, pp. 88-93, April 1990.
[7] Hanselmann, H., “DSP-Based Automotive SensorSignal Generation for Hardware-in-the-LoopSimulation,” SAE paper No. 940185, 1994.
[8] Hendricks, E., Vesterholm, T. and Sorenson, S. C.,“Nonlinear, Closed-loop, SI Engine ControlObservers,” SAE paper No. 920237, 1992.
[9] Kaidantzis, P., et al., “Advanced Nonlinear ObserverControl of SI Engines,” SAE paper 930768, 1993.
[10] Chang, C., Fekete, N.P. and Powell, J.D., “Engine Air-Fuel Ratio Control Using an Event-Based Observer,”SAE paper 930766, 1993.
[11] Kao, M.H. and Moskwa, J.J., “Engine Load andEquivalence Ratio Estimation for Control andDiagnostics via Nonlinear Sliding Observers,”International Journal of Vehicle Design, Vol. 15, No.3/4, 1994..
[12] Shiao, Y.J. and Moskwa, J.J., “Cylinder Pressure andCombustion Heat Release Estimation for SI EngineDiagnostics Using Nonlinear Sliding Observers,” IEEETransactions on Control Systems Technology, March1995.
[13] Kao, M.H. and Moskwa, J.J., “Nonlinear Diesel EngineControl and Cylinder Pressure Observation,” ASME J.of Dynamic Systems, Measurement and Control ,(accepted March 1994).
[14] Shiao, Y. and Moskwa, J.J., “Misfire Detection andCylinder Pressure Reconstruction for SI Engines,” SAEpaper No. 940144* , 1994.
[15] Ault, B.A., et al., “Adaptive Air-Fuel Ratio Control of aSpark-Ignition Engine,” SAE paper No. 940373, 1994.
[16] Turin, R.C. and Geering, H.P., “Model-Based AdaptiveFuel Control in an SI Engine,” SAE paper No. 940374,1994.
[17] Kao, M.H. and Moskwa, J.J., “Nonlinear Cylinder andIntake Manifold Pressure Observers for Engine Controland Diagnostics,” SAE paper No. 940375, 1994.
[18] Amstutz, A., et al., “Model-Based Air-Fuel RatioControl in SI Engines with a Switch-Type EGOSensor,” SAE paper No. 940972, 1994.
[19] Cho, D. and Oh, H., “Variable Structure ControlMethod for Fuel-Injected Systems,” ASME J. of
* References [14-17] can also be found in SAE special
publication Electronic Engine Controls 1994 (SP-1029).
Dynamic Systems, Measurement and Control, Vol. 115Sept. 1993.
[20] Cho, D., “Nonlinear Control Methods for AutomotivePowertrain Systems,” Department of MechanicalEngineering, M.I.T., Ph.D. thesis, 1987.
[21] Cho, D. and Hedrick, J.K., “Automotive PowertrainModeling for Control,” ASME J. of Dynamic Systems,Measurement and Control, 114(4), pp. 568-576, 1989.
[22] Weeks, R.W., “Implementation Issues in Sliding ModeAutomotive Powertrain Controllers,” Department ofMechanical Engineering, M.I.T., Sc.M. thesis, 1988.
[23] McMahon, D.H., et al., “Longitudinal VehicleControllers for IVHS: Theory and Experiment,” inProc. American Contr. Conf., 1992.
[24] The MathWorks, Inc., SIMULINK Accelerator User'sGuide, April, 1994.
[25] The MathWorks, Inc., SIMULINK Real-Time WorkshopUser's Guide, May, 1994.
NOMENCLATURE
ADC analog to digital converteralpha throttle angle (degrees)AMS air-mass sensorAMStau air-mass sensor time constant (s)C1 speed-density constantDSP digital signal processorEGR exhaust gas recirculationEngSpeed, ωe engine speed (rad s)epsilon, ε fuel split parametergamma, γ fraction of fuel injected before IVCIAC idle air controlIVC intake valve closeMBT minimum spark for best torque (DBTDC).m, m-file MATLAB ASCII file.mex, MEX-file MATLAB object code file
mdot_ai, mai
•air flow rate into intake (kg s)
mdot_ao, mao
•air flow rate into cylinder (kg s)
mdot_egri, megri
•EGR flow rate into intake (kg s)
mdot_egro, megro
•EGR flow rate into cylinder (kg s)
mdot_fi, mfi
•fuel flow rate at injector (kg s)
mdot_fo, mfo
•fuel flow rate into cylinder (kg s)
mdot_ff2, mff
•2 fuel flow injected after IVC (kg s)
mdot_ff3, mff
•3 fuel flow injected before IVC (kg s)
mdot_fs1, mfs
•1 fuel flow lagged by wall wetting (kg s)
OBDII On-Board Diagnostics IIPamb ambient air pressure (kPa)Pexh exhaust manifold pressure (kPa)Pman intake manifold pressure (kPa)
SAE 950417 Weeks & Moskwa 3/24/95 -14-
R perfect gas constant (for air R=287J kg K° )S/D speed-densitySFI sequential fuel injectionSOI start of injectionSOItoIVC_deg Φ ΦIVC SOI−VE, ηvol volumetric efficiency of engine (unitless)
Veng, Vdisp engine displacement (m3)
Vman intake manifold volume (m3)tauf, τ f slow fuel time constant (s)
Tamb ambient air temperature (°K )Tman intake manifold temperature (°K )ΦSOI crank angle at start of injection (degrees)Φ IVC crank angle at intake valve close (degrees)ΦPW injector pulse width in crank degrees∆T1, delta t1 fuel time delay from command to IVC (s)∆T2 , delta t2 two crank revolution fuel time delay (s)
SIMULINK ™ block diagram symbol
APPENDIX
SIMULINK BenchmarksThis section presents some of the execution times for the
engine and control system models described earlier in thepaper so readers can gauge the approximate time the modelswould take to run on their platform. The models described inthis paper were all simulated on a 50Mhz PC with 16Mb ofRAM using MATLAB 4.2 and SIMULINK 1.3. Some of thesimulations described later in the appendix also required theuse of two additional MathWorks “toolboxes.” For thesesimulations, the SIMULINK Accelerator™ (version 1.1) andthe Real-Time Workshop™ (version 1.1a) were used. TheAccelerator and the Real-Time Workshop both require a Ccompiler. For this, a WATCOM C/C++ 32 bit compiler wasused (version 9.5b).
The standard MATLAB benchmark program (bench.m)was run on the PC used to perform the SIMULINK simulations.Its performance relative to a group of other computers isshown in Fig. A1 so readers can assess how their platformcompares to the PC used to run the engine and control systemmodels. The PC’s performance is shown as “This computer”in the bar chart in Fig. A1. The bar chart shows relative speed,which is inversely proportional to the execution time. Longerbars are faster machines, shorter bars are slower.
0 50 100 150 200 2500
2
4
6
8
10Relative Speed
SPARC-1
Tadpole
This computer
IBM RS/6000, 320
SPARC-2
Iris Indigo
HP 710
SPARC-10
HP 720
Figure A1: PC’s performance (“This computer”) relative toseveral other computers executing the MATLAB benchmark
SIMULINK AcceleratorThe SIMULINK Accelerator increases the speed of a
simulation by generating C code for the SIMULINK model,compiling it as a MATLAB MEX-file, and dynamically linkingit in place of the original internal model representation. Whenthe Accelerator is enabled (as shown in Fig. A2) and asimulation is started, SIMULINK first looks for a MEX-filewhose name matches that of the SIMULINK model. If theMEX-file does not exist or is not up to date a new MEX-file isautomatically generated and executed.
Figure A2: Enabling the simulation “Accelerate” option
Some of the simulations in the Fuel DynamicsParametric Study (presented earlier) were run both with andwithout the “Accelerate” option enabled. Without theaccelerator a set of four simulations took 548.8 seconds toexecute on a 50Mhz 486 PC. With the accelerator enabled thesimulation time dropped to 148.8 seconds for an improvementfactor of 3.7. As the complexity and number of blocks in amodel increases the improvement factor also tends to increaseto an upper limit of about 7.1 [24].
When running short simulations during modeldevelopment it is sometimes better to disable the accelerateoption if a lot of changes are being made to the block diagram.This avoids the time taken to generate and compile the C codebefore a “run” is made. If the simulations take longer than aminute or so, it is usually faster to use the Accelerator even ifit has to regenerate and recompile the C code before each run.For example, the engine and control system model takes 135seconds to run one “3 second” simulation when theAccelerator is not present, dropping to 40 seconds (for animprovement factor of 3.37) if the Accelerator is enabled but itdoes not have to regenerate or recompile C code.
If a change is made to the block diagram that forces theAccelerator to regenerate C code, the total simulation timeincreases to about 88 seconds of which 54 seconds arerequired to generate and compile the C code and 34 secondsare required to run the simulation. For most reasonably largemodels it is best to always leave the Accelerator enabled.
The C code generated by the Accelerator option isuncommented and cannot be compiled and run as a standaloneprogram. The SIMULINK Real-Time Workshop should beused if commented C source code is desired that can becompiled and run on a variety of target processors.
SAE 950417 Weeks & Moskwa 3/24/95 -15-
SIMULINK Real-Time WorkshopThe SIMULINK Real-Time Workshop is an automatic C
language generation environment for SIMULINK . It producesC code directly from SIMULINK graphical models andautomatically builds programs that can be run in real-time in avariety of environments [25]. With the Workshop, SIMULINKmodels can be run in real-time on a remote processor(assuming the processor is sufficiently fast). It can also beused to generate accelerated stand-alone versions of modelsthat can be run on the host computer or on an externalcomputer. C source code can be generated for both real-timeand nonreal-time simulations. When “Real-time Options...” isselected with the mouse (as shown in Fig. A3) a dialog box(shown in Fig. A4) appears to allow some customization ofoptions such as the integration algorithm and step size and datalogging.
Figure A3: Selecting the C code generation real-time options
The engine and control system model shown in Fig. A3will not run in real-time on a 50Mhz PC. A nonreal-time DOSexecutable model (generated using the “Nonreal-timeOptions”) will perform a “3 second” simulation run in 25seconds of actual time using variable time step Runge-Kuttaintegration. Running the same model using Euler integrationand a fixed time step of 1/2 millisecond reduces the simulationtime to 9 seconds but with a slight loss in simulation accuracy.Real-time execution speeds should be possible on a PC basedDSP board or possibly on a higher clock speed Pentium PC.The authors plan to determine the minimum platform neededfor real-time execution so that hardware-in-the-loop testing canbe performed using the engine model in place of a real engine.
Figure A4: Options available for real-time code generation(after selecting “Real-time Options...” in Fig A3)