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 bobweeks@simcar.com

http://www.simcar.comJohn Moskwa (608) 263-2423 moskwa@engr.wisc.edu

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)