Engine Modeling for Real-time Control Using Simulink

SAE 950417

Automotive Engine Modeling for

Real-Time Control Using

M

ATLAB

/S

IMULINK

Robert W. Weeks Modular Systems

John J. Moskwa Powertrain Control Research Laboratory University of Wisconsin-Madison This paper was published and presented at the Society of Automotive Engineers

1995 International Congress and Exposition, Detroit, MI. For more information you can contact:

Phone: Internet: SAE (412) 776-4841

Robert Weeks (847) 869-2023 bobweeks@simcar.com http://www.simcar.com John Moskwa (608) 263-2423 moskwa@engr.wisc.edu

ABSTRACT

The use of graphical dynamic system simulation software is becoming more popular as automotive engineers strive to reduce the time to develop new control systems. The use of model-based control methods designed to meet future emission and diagnostic regulations has also increased the need for validated engine models. A previously validated, nonlinear, mean-torque predictive engine model* is converted to

MATLAB / SIMULINK† to illustrate the benefits of a graphical

simulation environment. The model simulates a port-fuel-injected, spark-ignition engine and includes air, fuel and EGR dynamics in the intake manifold as well as the process delays inherent in a four-stroke cycle engine. The engine model can be used in five ways:

• As a nonreal-time engine model for testing engine control algorithms

• As a real-time engine model for hardware-in-the-loop testing

• As an embedded model within a control algorithm or observer

• As a system model for evaluating engine sensor and actuator 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 of spark-ignition engines. Modular programming techniques reduce model complexity by dividing the engine and control system into hierarchical subsystems.

* _{Developed under a contract from the Power Systems}

Research Department of General Motors Research Laboratories.

† _{MATLAB and SIMULINK are trademarks of The}

MathWorks, Inc.

INTRODUCTION

Dynamic system simulation software is an important tool for developing reliable, low emission engine and powertrain control systems. Several companies market software (and hardware) that can be used to rapidly simulate a dynamic system and its controller using various combinations of PC and/or workstation technology.‡ Many of these companies provide software tools that allow development of libraries of component models. As these component model libraries are developed, new control systems are easily simulated by reusing previously built subsystems.

In an effort to develop some of these reusable subsystem models, a previously validated mean torque predictive engine model was converted from FORTRAN to MATLAB /

SIMULINK.§ The SIMULINK engine model is simulated

within a larger system model that also includes sensor, actuator and engine controller subsystem models.

The paper begins with an overview of the engine and control system model briefly describing the various subsystems. Additional detail is provided for the engine model’s intake manifold subsystem before a series of example simulations are examined. The example simulations illustrate how mean torque predictive models can be useful for predicting a number of variables important to the control system engineer. Execution times for the model are provided in the appendix.

‡ _{A partial list includes: The MathWorks, Inc., Integrated}

Systems, Inc., dSPACE GmbH, Xanalog Corp. and Visual Solutions, Inc.

§ _{A complete theoretical review of the mean torque}

predictive engine model is beyond the scope of this paper. Readers interested in a detailed development of the engine model should refer to [1,2,3].

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 block diagram language allows models to be written in a modular, hierarchical format. The overall system model in Fig. 1 simulates an engine and control system consisting of an engine, engine sensors and actuators and an engine controller. Inputs to the engine include: throttle angle, an external load torque such as that due to a dynamometer or a transmission, ambient conditions (i.e., atmospheric temperature and pressure) and actuator inputs from various “actuators” such as fuel injectors, EGR valve, etc. All the important engine variables are “vectored” and made available to other subsystems such as Sensors, Actuators and Data Analysis. Before a simulation is run the Load Vehicle Specific Data block must be double-clicked with a mouse. This executes an m-file script which loads all of the vehicle specific parameters into MATLAB’s workspace memory. By separating vehicle specific data from the subsystem models, the models are more generic, allowing development of one model that simulates several engines.

Engine

The inside of the Engine block (from Fig. 1) is shown below in Fig. 2. This block “demuxes” all the engine’s inputs and routes them into the Mean Torque SFI Engine block. The Mean Torque SFI Engine block contains a SIMULINK

version of the engine model described in [1]. All the important variables from the engine model are routed into the Engine Variable Connector where they are “muxed” into a vector* _{called Engine Variables.}

mdot_fi 3 alpha 2 Tload 1 Ambient Conditions Pin Tin 4 Actuator Outputs Demux Demux spark_advance inj_pw_deg mdot_IAC mdot_egri Demux Demux1

Mean Torque SFI Engine

Engine Variable Connector 1 Engine Variables

Figure 2: Engine block (from Fig. 1)

* _{Vectors in SIMULINK 1.3 are normally shown as thick}

Sensors

The Sensors block visible in Fig. 1 contains all the engine sensor models (shown in Fig. 3). A subset of the engine variables are routed into individual sensor models. Each sensor may be modeled to the degree of accuracy necessary for a given simulation. 7 out_7 8 out_8 4 out_4 5 out_5 3 out_3 6 out_6 2 out_2 1 out_1 8 in_8 7 in_7 6 in_6 5 in_5 4 in_4 3 in_3 2 in_2 1 in_1 double-click to plot sensor tables Engine Speed

Sensor Temperature SensorAmbient Air

Manifold Absolute Temperature Sensor Air Mass Sensor Baro Sensor Manifold Absolute Pressure Sensor Throttle Position Sensor Exhaust Gas Oxygen Sensor

Figure 3: Sensors block (from Fig. 1) Controller

The contents of the Controller block shown in Fig. 1 are shown below in Fig. 4. Discrete time control algorithms are placed inside the Control Algorithms block which is “wired” between the input and output signal conditioning blocks. The Input Signal Conditioning block performs the conditioning necessary to convert the simulated sensor outputs to the engineering units typically used by the Control Algorithms block. This often involves analog-to-digital converter models and conversion tables. The Output Signal Conditioning block converts control signals to the type of signal necessary for the engine’s control actuators, such as a pulse width modulated signal, a desired stepper motor position, etc.

1 Sensor Outputs Controller Variables Digitized Inputs Input Signal

Conditioning AlgorithmsControl

Output Signal Conditioning 1 Actuator Inputs 2 Controller Variables

Figure 4: Controller block (from Fig. 1) Actuators

The contents of the Actuators block (from Fig. 1) are shown below in Fig. 5. Four actuators are used for this engine control system, including fuel injectors, an ignition system, an exhaust gas recirculation valve and an idle air control valve. The actuator commands (from the controller) come in through inport 1. A Signal Select block was created to split the actuator signal vector (or “harness”) and route the signals to the appropriate actuator models. Each of the actuators has a mass flow rate for its output, except for the Ignition System block where the output is simply a value for the current spark advance. The Fuel Injectors block also determines the injector pulse width in degrees of crank rotation. This is used in the engine model to determine if a portion of the fuel pulse

is injected after the intake valve closes (and thus goes through an additional delay before entering the cylinder).

IAC_cmd mdot_IAC IAC Valve EGR Valve Ignition System Fuel Injectors mdot_fi inj_pw_deg spark_adv double-click to plot actuator tables 2 Engine Variables SA_cmd mdot_fi_cmd EGRvalve_cmd Mux Mux 1 mdot_egri Signal Select (using mux) 1 Actuator commands

Figure 5: Actuators block (from Fig. 1)

The mass flow rates through the EGR and IAC valves are affected by the stagnation conditions upstream of the valves as well as the pressure drop across the valves. These two valve models are therefore connected to the Engine Variables vector allowing access to the appropriate pressures and temperatures from the engine model. Separating the actuator models from the engine model allows revisions (or substitutions) of the actuator models without updating the engine model. This type of modularity makes the engine model more generic.

Data Analysis

The contents of the Data Analysis block (from Fig. 1) are shown below in Fig. 6. This block is used strictly for storing data to the MATLAB workspace (or to disk) as well as for visualizing variables during a simulation run (typically with

SIMULINK scope blocks). The Data Analysis block can be

removed from the overall control system model without affecting the simulation. It simply provides a convenient method for comparing variables in the engine to variables in the controller. Engine and controller variable vectors are “demuxed” in the Data Analysis block to make it easy to select arbitrary combinations of variables for visualization during a simulation run.

1 Controller Variables 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_ao 7 mdot_ai 6 EngSpeed 5 EGRfrac 4 alpha 2 AFexh 1 AFego Demux Demux 2 Engine 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 throttle flow rates display pressures Save Results display port flow rates

MEAN TORQUE SFI ENGINE MODEL

The Engine block briefly described in the previous section is more thoroughly described in this section. The engine model is physically based and captures the major dynamics (lags and delays) inherent in the spark ignition torque production process. It is a continuous time delay, mean torque-predictive model designed primarily for the control engineer. It does not attempt to predict flow and torque pulsations due to individual cylinder filling events. The engine model was derived from the four state, lumped parameter dynamic engine model developed in [1].

The Mean Torque SFI Engine block (from Fig. 2) is shown below in Fig. 7. This block consists of four subsystem blocks: the Throttle Body, the Intake Manifold, the Engine Block and the Exhaust Manifold.

mdot_ai 7 mdot_throt 14 11 Mux Mux 5 mdot_fi 6 inj_pw_deg Throttle Body 13 18 15 4 2 Tamb 1 Pamb 4 alpha 9 mdot_IAC 9 8 mdot_egri 2 EngSpeed torq_indicated Texh Tcool AFexh 16 1 AFego Pexh 6 20 19 22 torq_fric_pump Exhaust Manifold 23 Engine Block 7 spark_adv 3 Tload 10 5 3 12 8 21 17 mdot_egro EGRfrac AFport mdot_fo mdot_ao Tman Pman Intake Manifold double-click to plot engine specific tables

Figure 7: Mean Torque SFI Engine block (from Fig. 2) The Throttle Body block calculates the total mass flow rate of air entering the intake manifold (mdot_ai). One-dimensional isentropic compressible flow equations determine the throttle flow rate (mdot_throt) as a function of throttle angle (alpha), intake manifold pressure (Pman), and upstream stagnation conditions (Pamb and Tamb). The total flow rate into the manifold is simply the sum of the throttle flow rate, the idle air control valve flow rate, and the flow due to any intake manifold leaks as shown below in Fig. 8. The throttle flow rate calculations used in the throttle body model have also proven useful in engine controllers for constructing “observers” that estimate the transient air flow rate at the throttle and intake ports of an engine [4].

P and T Correction * Product * Product1 Vacuum Leak Flow + + + Sum 1 mdot_ai 4 Tamb 2 mdot_throt mdot_leak 2 alpha _{Throttle Flow}

5 mdot_IAC -K-Leak Size divide 1 Pman 3 Pamb PR Repeating Sequence

Figure 8: Throttle Body block (from Fig. 7)

The Intake Manifold block’s main purpose is to determine the manifold pressure as well as the mean-value mass flow rates of air, fuel and EGR in the intake ports of the engine. A more complete description is given in the Intake Manifold subsection that follows.

The Engine Block’s main purpose is to perform the torque production and rotational dynamics calculations. Double clicking two levels down into the Engine Block block reveals 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 pumping torque of the engine (torq_fric_pump) to get the brake torque (torq_brake). Any external load torques are then subtracted from the brake torque to determine the net torque which accelerates or decelerates the crankshaft. The crankshaft acceleration is then integrated to get the engine speed (EngSpeed). 1/s Integrator Friction and Pumping Torque (tbl) EngLoad 1 torq_indicated 2 torq_fric_pump 5 Load torque torq_brake 3 EngSpeed -K-1/Je + -Net torque -+ Sum Calculate Indicated Torque 2 Pman 1 EGRfrac 6 spark_adv 4 AFport 3 mdot_ao

Figure 9: Torque Production block Intake Manifold

The Intake Manifold block (mentioned earlier in the MEAN TORQUE SFI ENGINE MODEL section) is more thoroughly examined in this subsection to lay the groundwork for a parametric study presented later in the EXAMPLE SIMULATIONS section of the paper. The contents of the Intake 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 flow rate which assumes a homogeneous mixture of air and EGR. The port EGR flow rate (mdot_egro) is then subtracted from the total port flow rate (air + EGR) to determine the port air flow rate (mdot_ao). The port fuel flow rate (mdot_fo) is assumed to not interact with the air or EGR dynamics.* An intake port air/fuel ratio is calculated by simply dividing the port air flow rate by the port fuel flow rate.

1 Pman + -Sum EGR Dynamics Air Dynamics 4 mdot_fo 3 mdot_ao EGR fraction 6 EGRfrac divide 5 AFport 7 mdot_egro 1 mdot_ai Tman Tman 2 3 mdot_egri 4 EngSpeed Fuel Dynamics 2 mdot_fi and inj_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 its affect on air or EGR flow.

Air Dynamics

The contents of the Air Dynamics block from Fig. 10 are shown below in Fig. 11. The Manifold filling dynamics block (from Fig. 11) calculates the intake manifold pressure (Pman) using a block diagram version of Eq. 1 [1]:

d dtP T T C P R T V m m man man man e vol man man man ai egri =

F

− ⋅ ⋅

HGG

I

KJJ

⋅ + ⋅ ⋅

FH

+

IK

• • • 1 ω η . (1)

The Port flow rate block in Fig. 11 determines the total port flow rate using a speed-density calculation. The model assumes air and EGR are homogeneously mixed and have the same molecular weight and temperature. With this simplification it is possible to estimate the combined mass flow rate of air and EGR entering the cylinders using a traditional speed-density calculation. In practice, it is difficult to determine the percentage of the combined flow rate due to air flow alone (mdot_ao). In the model this value is calculated by subtracting the EGR flow (mdot_egro) from the combined flow (see Fig. 10).

2 Pman 1 Total port flow rate 3 VE 2 mdot_ai 4 mdot_egri 3 EngSpeed 1 Tman Manifold filling dynamics Port flow rate

Figure 11: Air Dynamics block (from Fig. 10) Fuel Dynamics

The contents of the Fuel Dynamics block visible in Fig. 10 are shown below in Fig. 12. The calculations performed in the Fuel Dynamics block are based on Eqs. 2-6 below [1,3]. A fraction of the mean injector flow rate (shown as mdot_fi in Fig. 12), goes through one or two pure time delays as well as a first order lag before it finally enters the cylinders as mdot_fo. The pure time delay, t

b

− ∆T₁

g

, represents the average delay from a change in the fuel command to the actual start of injection (SOI) plus the delay from the start of injection until the intake valve closes (IVC). This delay is performed by the

fuel delay (delta t1) block in Fig. 12. The delay, t

b

− ∆T₂

g

,

represents a two revolution delay for any fuel injected after the intake valve closes (see the 2 rev delay (delta t2) block in Fig. 12).

epsilon and tauf are shown as constants here but in general are time varying functions of speed, load, temperature, etc.

if intake valve closes while fuel is injected then some fuel gets delayed two revs 2 EngSpeed 2 rev delay (delta t2) fuel delay (delta t1) gamma -₊ Sum1 slow fuel mdot_fs1 tauf slow fuel time constant epsilon fuel split 1 mdot_fi and inj_pw_deg * Product1 fast fuel + -Sum Time varying Lag filter Slow fuel lag

mdot_ff2 * Product 1 mdot_fo + + + Sum2 mdot_ff3

Figure 12: Fuel Dynamics block (from Fig. 10) The fuel split parameter,

ε

, is the fraction of the injected fuel 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 the injected fuel with transport properties of a liquid fuel. It is called “tauf” in Fig. 12. The variable, γ, is the fraction of the fuel injected before the intake valve closes. It is calculated and output from the gamma block in Fig. 12. The values of “epsilon” and “tauf” are shown as constants in Fig. 12, but in general are time varying as a function of manifold temperature, pressure and engine speed. A table of values could easily be substituted for the constants in Fig. 12.

mfo mff mff mfs • • • • = 2+ 3+ 1 (2) where: mff mfi t T t T • • − ₋ =

L

⋅ ⋅ −

NM

O

QP

2 1 2 1 ∆ _∆

b g

ε

b g

γ

_b

_g

(3) mff mfi t T • • − = ⋅ ⋅ 3 1 ∆

b g

ε γ (4) d dt m 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 PW PW IVC SOI (6)

ENGINE SPECIFIC TABLES

Before an engine simulation is run, the MATLAB

workspace memory must be loaded with all the parameters that are specific to a particular engine. This is usually done by double-clicking on the Load Vehicle Specific Data block in Fig. 1 but can also be done by just typing “simspec” at the

MATLAB prompt. Both methods run an m-file script called

“simspec.m”. This m-file actually executes a number of other m-files which all contain data specific to one or more of the subsystem models. A partial listing of simspec.m follows:

...

% 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; for example “ambspec” executes the script file ambspec.m which initializes the variables used for ambient temperature and pressure. Tables are used for many of the engine specific parameters even if an analytical expression could have easily been embedded in the SIMULINK model.* _{Tables make the}

model more generic because they have more degrees of freedom than an analytical expression or regression equation. In some cases tables are initialized using regression equations. This gives additional flexibility without the need to embed engine specific equations in the SIMULINK model.

In addition to initializing a number of engine specific constants such as engine displacement (Veng) and intake manifold volume (Vman), the m-file engspec.m loads nine engine 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 to the 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 a large extent on the number of the above tables calibrated to represent the engine of interest. The model was originally validated using a naturally aspirated, sequential port fuel injected, 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 to recalibrate all of the above tables.

EXAMPLE SIMULATIONS

Several simulations were run to demonstrate the output of the engine and control system model. Unless otherwise specified 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 is shown in Fig. 13. After one second the throttle is ramped from 5 to 20 degrees at a rate of 900 degrees/second. At the two second simulation time the throttle is ramped back to 5 degrees. No external load torques are applied to the engine, so the simulation approximates a free-revving engine’s response to a rapid throttle transient.

0 1 2 3 4 5 0 10 20 30 40 50 60 70 80 Time (sec) T h ro tt le A n g le (d e g re e s )

Figure 13: Throttle trajectory for example simulations Baseline using Air Mass Sensor

Figures 14-19 illustrate the output of the engine and control system model when an air mass sensor is used by the controller to calculate a fuel command. Throttle and intake port air flow rates (mdot_ai and mdot_ao, respectively) are illustrated in Fig. 14. Note that a small manifold filling spike appears in the throttle flow rate as the throttle is opened.

Throttle Port 0.5 1 1.5 2 2.5 3 0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 A ir fl o w ra te (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 the injector flow rate is due to the 8 bit analog to digital converter used to “measure” the air mass sensor as well as ±1

2 bit of

noise included in the ADC model. The lag in the intake port flow rate is due to the fuel dynamics, described earlier.

Injector Intake Port 0.5 1 1.5 2 2.5 3 0 1 2 3 4 5x 10 -3 F u e l fl o w r a te ( k g /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 to fuel dynamics are not canceled by the lead information provided by the air mass sensor. The combination of the two still results in a lean excursion due to throttle openings and a rich excursion when the throttle closes.*

* _{On some port fuel injected engines with large intake}

manifolds it is possible for the lead information from the air mass sensor to cause a rich excursion on throttle openings.

0.5 1 1.5 2 2.5 3 0 10 20 30 40 50 In ta k e P o rt A /F Time (sec)

Figure 16: Intake port air/fuel ratio using an air-mass sensor fuel calculation

Intake and exhaust manifold absolute pressures are shown in Fig. 17. The intake manifold pressure drops below 53 kPa as the simulation time exceeds 1.25 seconds. This causes the flow rate at the throttle to choke and thus not increase even as engine speed rises.

Intake Exhaust 0.5 1 1.5 2 2.5 3 0 50 100 150 M a n if o ld pr ess u re ( k Pa) Time (sec)

Figure 17: Intake and exhaust manifold absolute pressures The engine’s indicated torque is plotted in Fig. 18 along with the value of its friction and pumping torque. The initial throttle tip-in causes an air/fuel excursion lean enough to result in a “misfire” where indicated torque momentarily drops to zero. As engine speed increases, the internal friction and pumping torque of the engine approaches the value of the indicated torque causing engine speed to level off because there is no net torque available to continue accelerating the crankshaft.

Indicated Friction/Pumping 0.5 1 1.5 2 2.5 3 0 20 40 60 80 100 120 140 160 Tor q u e ( N *m ) Time (sec)

Figure 18: Engine indicated and friction/pumping torque using an air-mass sensor fuel calculation

The engine speed quickly accelerates from about 2500 RPM to nearly 6500 RPM during the throttle trajectory because there is no load on the crankshaft. This is illustrated in Fig. 19 below. A very slight drop in engine speed is observed at the start of the throttle tip-in due to the momentary drop in indicated torque.

0.5 1 1.5 2 2.5 3 200 300 400 500 600 700 En g in e Speed ( rad/ s) Time (sec)

Figure 19: Engine speed using an air-mass sensor fuel calculation

Baseline using Speed-density

This subsection illustrates some of the differences in engine performance when a speed-density calculation in the controller model determines the fuel command. In the baseline simulations, no additional acceleration enrichment or deceleration enleanment algorithms are tested. The speed-density fuel rates comparable to those in Fig. 15 are shown below in Fig. 20. The fuel flow rate does not rise as quickly as it did in the air-mass sensor baseline condition. This causes even larger air/fuel excursions than the air-mass sensor baseline (as evident in Fig. 21). In both sets of baseline simulations the throttle tip-in causes a relatively large lean spike in the intake port air/fuel ratio. This is primarily due to the pure time delays in the fuel dynamics portion of the engine

model. In the air-mass sensor baseline, the rapid rise in the air flow rate measurement (as compared to speed-density) improves transient fueling even though a speed-density system is theoretically better matched to a port-fuel-injection engine [4]. Injector Intake Port 0.5 1 1.5 2 2.5 3 0 1 2 3 4 5x 10 -3 F u e l fl o w r a te ( k g /s ) Time (sec)

Figure 20: Injector and intake port fuel flow rates using a speed-density fuel calculation

0.5 1 1.5 2 2.5 3 0 10 20 30 40 50 In ta k e P o rt A /F Time (sec)

Figure 21: Intake port air/fuel ratio using a speed-density fuel calculation

The larger lean air/fuel excursion for the speed-density baseline causes a significant drop in indicated torque after the throttle tip-in (as shown in Fig. 22). The longer duration drop in torque is caused by more cylinders misfiring due to the lean condition (as compared to the air mass sensor baseline), causing a noticeable drop in engine speed (see Fig. 23). The drop in speed would probably be felt as a “stumble” if the engine were running in a vehicle.

Indicated Friction/Pumping 0.5 1 1.5 2 2.5 3 0 20 40 60 80 100 120 140 160 Tor q u e ( N *m ) Time (sec)

Figure 22: Engine indicated and friction/pumping torque using a speed-density fuel calculation

0.5 1 1.5 2 2.5 3 200 300 400 500 600 700 En g in e Speed ( rad/ s) Time (sec)

Figure 23: Engine speed using a speed-density fuel calculation (note tip-in “stumble”)

Fuel Dynamics Parametric Study

One of the advantages of using SIMULINK is that models can be developed and run interactively using a graphical interface and also run from the MATLAB command line. This makes it easier to perform parametric analyses to examine the effects of varying different constants in the model. With the help of optimization tools the model parameters can often be automatically “tuned” to minimize a “cost” function and thus maximize some user-defined performance criteria. It is sometimes possible to “fit” the model to measured engine data by using commercially available optimization algorithms to automatically adjust model parameters.*

This subsection demonstrates how the engine model may be used in a simple fuel dynamics parametric study to determine the effects of varying some of the fuel parameters mentioned earlier. The first parameter varied is the start of injection to intake valve closing angle (SOItoIVC_deg).

* _{The Levenberg-Marquardt method was originally used}

to identify the dynamic fuel parameters for this model from engine data on a dynamometer [3].

SOItoIVC_deg represents the number of degrees the crankshaft rotates from when the fuel injector is opened to when the intake valve (for that injector’s cylinder) closes. Most sequential port fuel injection systems control the timing of the injection relative to the intake valve opening so there is an interest in understanding how this affects air/fuel ratio control and emissions.

There is a transient fueling advantage for waiting until the intake valve nearly closes before injecting a given cylinder’s fuel, but if the injector is still open after the valve closes, part of the fuel will have to wait in the intake port for nearly two revolutions until the valve opens again. This contributes to transient air/fuel ratio errors.

There is often a steady-state fueling advantage to injecting fuel after the intake valve closes so it has the longest possible residence time in the intake port. This allows more time for the fuel to vaporize in the vicinity of a hot intake valve and can sometimes lower steady-state emission levels.

The two strategies are diametrically opposed to one another making it difficult to determine the best time to inject fuel relative to the intake valve closing. The engine and control system model can be used to help evaluate fueling strategies related to transient air/fuel control and how it is affected by injection timing. The following MATLAB script file shows how the engine and control system model shown in Fig. 1 can be executed within a loop to determine the effect of varying 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 simulations of the engine and control system model (engsim.m) using a Runge-Kutta integration algorithm. SOItoIVC_deg is varied from 0 degrees up to 720 degrees in 240 degree increments. The results of each simulation are stored in a different file as follows:

Another m-file was written to load the results and plot the intake port air/fuel ratio versus simulation time (shown in Fig. 24). In the first run the fuel is injected right as the intake valve closes where it would remain in the port for nearly two revolutions before the valve reopens. During the throttle transient the air flow rate changes significantly during two revolutions of the crankshaft. This effect contributes a substantial portion of the air/fuel ratio error shown in the first run. In the second run (where SOItoIVC_deg=240) the fuel injection is completed at about the same time as the intake valve closing. This helps to minimize the transient air/fuel errors but does not allow the fuel as much time to vaporize in the intake port. The third and fourth runs show that when fuel is injected a significant time before the intake valve closes the transient air/fuel errors will again increase. To help minimize these transient air/fuel ratio errors, some injection strategies control the end of injection relative to intake valve closure rather than the start of injection.

Previous steady state engine testing has shown that injection of fuel while the intake valve is open can lead to increased emissions (due to poor vaporization and exhaust backflow effects) but injection of fuel while the valve is closed can lead to transient air/fuel ratio errors (which also leads to increased emissions). An ideal strategy would be one that

could predict the air flow rate at the ports approximately two crankshaft revolutions in the future and then inject the proper fuel pulse (allowing for fuel dynamics) right after the intake valve closes. This would allow the most time for fuel vaporization but would not suffer from transient air/fuel errors due to injection timing. An accurate prediction of future port air flow rates would require a drive-by-wire throttle so the engine controller could know the throttle’s trajectory over the next two crankshaft revolutions. Then using an embedded intake manifold model (similar to the one described in this paper), the controller would predict future port air flow rates as 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 the effects of varying SOItoIVC_deg. A similar set of parametric runs were performed where the values used for the fuel split parameter (epsilon) and the slow fuel time constant (tauf) were varied. These results are shown in Figs. 25 and 26. As epsilon approaches a value of one (see fourth plot in Fig. 25) the liquid fuel dynamics become negligible and most of the air/fuel error is due to the pure time delay, ∆T1 (see subsection on fuel

dynamics). A similar effect occurs as the slow fuel time constant (tauf) approaches zero (shown in the first plot in Fig. 26).

The example simulations and the parametric study presented here illustrate some of the possible uses of the mean torque predictive engine model. Other uses of the model are described (but not illustrated) in the SUMMARY and CONCLUSIONS section. 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o SO ItoIVC_deg= 0 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o SO ItoIVC_deg= 240 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o SO ItoIVC_deg= 480 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o SO ItoIVC_deg= 720 Time (sec)

Figure 24: Effects of varying start of injection relative to intake valve closing

file name test condition

SOI0.mat SOItoIVC_deg=0 SOI1.mat SOItoIVC_deg=240 SOI2.mat SOItoIVC_deg=480 SOI3.mat SOItoIVC_deg=720

0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o epsilon= 0.00 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o epsilon= 0.33 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o epsilon= 0.66 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o epsilon= 1.00 Time (sec)

Figure 25: Effects of varying fuel split parameter, epsilon

0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o tauf= 0.001 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o tauf= 0.11 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o tauf= 0.22 0.5 1 1.5 2 2.5 3 0 50 A/ F r a ti o tauf= 0.33 Time (sec)

SUMMARY and CONCLUSIONS

An automotive engine model designed for real-time control applications has been presented in the context of a

SIMULINK engine and control system model. Subsystems

within the model were briefly described with some additional detail related to the air and fuel dynamics portion of the intake manifold subsystem. Example simulations were presented to show 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 engine

control algorithms. Nonreal-time testing allows researchers and engineers to develop new control algorithms without the hardware constraints and software complexities of running in real-time.* _This

allows new ideas to be rapidly evaluated using high level languages such as graphical block diagrams or C. High precision floating point calculations can be used on low cost computers to rapidly iterate algorithm designs until a robust control law is found. Algorithms can often be evaluated in a matter of minutes or hours, whereas many conventional development systems require days or weeks to test new ideas because control algorithms must be written in assembler and tested on an actual vehicle.

2. As a real-time engine model for hardware-in-the-loop testing. Many engine models do a good job of simulating the dynamic behavior of an engine but are not designed to run in real-time. The engine model presented here, is physically based but relatively simple and uses a large number of table look-ups to reduce execution time. When converted to C (see appendix), the model may be executed on a variety of target processors. With a relatively low cost processor and appropriate I/O, the model may be used to evaluate the performance of actual engine sensors, controllers or actuators. For example, an actual engine controller (ECU) could be tested in a highly repeatable and deterministic manner using off-the-shelf simulation hardware [7].

3. As an embedded model within a control algorithm or observer. As model-based controls become more popular, simplified versions or subsystems of an engine model are often embedded into a real-time control algorithm [4-6,8-19]. The embedded model can predict engine variables that are difficult or impractical to measure. Observers or state estimators can also be used for diagnostic purposes, such as those mandated by OBDII.

4. As a system model for evaluating engine sensor and actuator models. Vehicle manufacturers will eventually require suppliers to provide models of the components

* _{Some examples of nonlinear sliding mode engine control}

algorithms (tested on the original FORTRAN version of the engine model described in this paper) are given in [5,6]. The algorithms use coordinated throttle and spark advance control to force the engine to track desired engine and transmission speed trajectories.

they sell so the manufacturer can do system simulations before prototype vehicles are built. When used as a system model, the engine and control system model can evaluate different sensor and actuator models. The modular design allows new sensor and/or actuator models to be tested without modifying the engine model. This makes it easier for component suppliers to perform system simulations of their sensor or actuator models without having to develop their own engine models.

5. As a subsystem in a powertrain or vehicle dynamics model. Mean torque predictive engine models are often incorporated into larger powertrain or vehicle dynamics models [20-23]. In general, as the complexity and size of a system model increases, the complexity of subsystem models must be reduced. Because of their relatively simple nature, mean torque predictive engine models are often more appropriate for vehicle simulations than models that predict individual cylinder filling phenomena.

Simulations are used by a large number of control system researchers but there is very little standardization in the plant models used for developing control laws. This makes it difficult to evaluate research showing the benefits of different control theories. A validated benchmark model makes it easier for control engineers at the vehicle manufacturers to evaluate control algorithms developed by researchers at various academic institutions. A benchmark model will allow comparison of new control algorithms in a very direct and repeatable manner. This will make it easier for vehicle manufacturers to identify promising control theories and techniques.

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 and Validation of Automotive Engines for Control Algorithm Development,” ASME J. of Dynamic

Systems, Measurement and Control, Vol. 114, No. 2,

pp. 278-285, June 1992.

[3] Moskwa, J.J., “Estimation of Dynamic Fuel Parameters in Automotive Engines,” ASME J. of Dynamic Systems,

Measurement and Control, December 1994.

[4] Weeks, R.W. and Moskwa, J.J., “Transient Air Flow Rate Estimation in a Natural Gas Engine Using a Nonlinear Observer,” SAE paper No. 940759, 1994. [5] Moskwa, J.J., “Sliding Mode Control of Automotive

Engines,” ASME J. of Dynamic Systems, Measurement

and Control, Vol. 115, No. 4, pp. 687-693, December

[6] Moskwa, J.J. and Hedrick, J.K., “Nonlinear Algorithms for Automotive Engine Control,” IEEE Control Systems

Magazine, Vol. 10, No. 3, pp. 88-93, April 1990.

[7] Hanselmann, H., “DSP-Based Automotive Sensor Signal Generation for Hardware-in-the-Loop Simulation,” SAE paper No. 940185, 1994. [8] Hendricks, E., Vesterholm, T. and Sorenson, S. C.,

“Nonlinear, Closed-loop, SI Engine Control Observers,” SAE paper No. 920237, 1992.

[9] Kaidantzis, P., et al., “Advanced Nonlinear Observer Control 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 and Equivalence Ratio Estimation for Control and Diagnostics 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 and Combustion Heat Release Estimation for SI Engine Diagnostics Using Nonlinear Sliding Observers,” IEEE

Transactions on Control Systems Technology, March

1995.

[13] Kao, M.H. and Moskwa, J.J., “Nonlinear Diesel Engine Control and Cylinder Pressure Observation,” ASME J.

of Dynamic Systems, Measurement and Control ,

(accepted March 1994).

[14] Shiao, Y. and Moskwa, J.J., “Misfire Detection and Cylinder Pressure Reconstruction for SI Engines,” SAE paper No. 940144* _{, 1994.}

[15] Ault, B.A., et al., “Adaptive Air-Fuel Ratio Control of a Spark-Ignition Engine,” SAE paper No. 940373, 1994. [16] Turin, R.C. and Geering, H.P., “Model-Based Adaptive

Fuel Control in an SI Engine,” SAE paper No. 940374, 1994.

[17] Kao, M.H. and Moskwa, J.J., “Nonlinear Cylinder and Intake Manifold Pressure Observers for Engine Control and Diagnostics,” SAE paper No. 940375, 1994. [18] Amstutz, A., et al., “Model-Based Air-Fuel Ratio

Control in SI Engines with a Switch-Type EGO Sensor,” SAE paper No. 940972, 1994.

[19] Cho, D. and Oh, H., “Variable Structure Control Method 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. 115

Sept. 1993.

[20] Cho, D., “Nonlinear Control Methods for Automotive Powertrain Systems,” Department of Mechanical Engineering, M.I.T., Ph.D. thesis, 1987.

[21] Cho, D. and Hedrick, J.K., “Automotive Powertrain Modeling for Control,” ASME J. of Dynamic Systems,

Measurement and Control, 114(4), pp. 568-576, 1989.

[22] Weeks, R.W., “Implementation Issues in Sliding Mode Automotive Powertrain Controllers,” Department of Mechanical Engineering, M.I.T., Sc.M. thesis, 1988. [23] McMahon, D.H., et al., “Longitudinal Vehicle

Controllers for IVHS: Theory and Experiment,” in

Proc. American Contr. Conf., 1992.

[24] The MathWorks, Inc., SIMULINK Accelerator User's

Guide, April, 1994.

[25] The MathWorks, Inc., SIMULINK Real-Time Workshop

User's Guide, May, 1994.

NOMENCLATURE

ADC analog to digital converter alpha throttle angle (degrees)

AMS air-mass sensor

AMStau air-mass sensor time constant (s)

C₁ speed-density constant DSP digital signal processor EGR exhaust gas recirculation EngSpeed, ω_e engine speed (rad s) epsilon,

ε

fuel split parameter

gamma, γ fraction of fuel injected before IVC IAC idle air control

IVC intake valve close

MBT 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 II Pamb ambient air pressure (kPa) Pexh exhaust manifold pressure (kPa) Pman intake manifold pressure (kPa)

R perfect gas constant (for air R=287 J kg K° )

S/D speed-density

SFI sequential fuel injection SOI start of injection SOItoIVC_deg Φ_IVC−Φ_SOI

VE, η_vol volumetric efficiency of engine (unitless) Veng, Vdisp engine displacement (m

3

) 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

∆T₁, delta t1 fuel time delay from command to IVC (s) ∆T₂, delta t2 two crank revolution fuel time delay (s)

SIMULINK™ block diagram symbol

APPENDIX

SIMULINK Benchmarks

This section presents some of the execution times for the engine and control system models described earlier in the paper so readers can gauge the approximate time the models would take to run on their platform. The models described in this paper were all simulated on a 50Mhz PC with 16Mb of RAM using MATLAB 4.2 and SIMULINK 1.3. Some of the simulations described later in the appendix also required the use of two additional MathWorks “toolboxes.” For these simulations, the SIMULINK Accelerator™ (version 1.1) and the Real-Time Workshop™ (version 1.1a) were used. The Accelerator and the Real-Time Workshop both require a C compiler. For this, a WATCOM C/C++ 32 bit compiler was used (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 is shown in Fig. A1 so readers can assess how their platform compares to the PC used to run the engine and control system models. 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. Longer bars are faster machines, shorter bars are slower.

0 50 100 150 200 250 0 2 4 6 8 10 Relative 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 to several other computers executing the MATLAB benchmark

SIMULINK Accelerator

The 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 linking it in place of the original internal model representation. When the Accelerator is enabled (as shown in Fig. A2) and a simulation is started, SIMULINK first looks for a MEX-file whose name matches that of the SIMULINK model. If the MEX-file does not exist or is not up to date a new MEX-file is automatically generated and executed.

Figure A2: Enabling the simulation “Accelerate” option Some of the simulations in the Fuel Dynamics Parametric Study (presented earlier) were run both with and without the “Accelerate” option enabled. Without the accelerator a set of four simulations took 548.8 seconds to execute on a 50Mhz 486 PC. With the accelerator enabled the simulation time dropped to 148.8 seconds for an improvement factor of 3.7. As the complexity and number of blocks in a model increases the improvement factor also tends to increase to an upper limit of about 7.1 [24].

When running short simulations during model development it is sometimes better to disable the accelerate option if a lot of changes are being made to the block diagram. This avoids the time taken to generate and compile the C code before a “run” is made. If the simulations take longer than a minute or so, it is usually faster to use the Accelerator even if it has to regenerate and recompile the C code before each run. For example, the engine and control system model takes 135 seconds to run one “3 second” simulation when the Accelerator is not present, dropping to 40 seconds (for an improvement factor of 3.37) if the Accelerator is enabled but it does not have to regenerate or recompile C code.

If a change is made to the block diagram that forces the Accelerator to regenerate C code, the total simulation time increases to about 88 seconds of which 54 seconds are required to generate and compile the C code and 34 seconds are required to run the simulation. For most reasonably large models it is best to always leave the Accelerator enabled.

The C code generated by the Accelerator option is uncommented and cannot be compiled and run as a standalone program. The SIMULINK Real-Time Workshop should be used if commented C source code is desired that can be compiled and run on a variety of target processors.

SIMULINK Real-Time Workshop

The SIMULINK Real-Time Workshop is an automatic C language generation environment for SIMULINK. It produces C code directly from SIMULINK graphical models and automatically builds programs that can be run in real-time in a variety of environments [25]. With the Workshop, SIMULINK

models can be run in real-time on a remote processor (assuming the processor is sufficiently fast). It can also be used to generate accelerated stand-alone versions of models that can be run on the host computer or on an external computer. C source code can be generated for both real-time and nonreal-time simulations. When “Real-time Options...” is selected with the mouse (as shown in Fig. A3) a dialog box (shown in Fig. A4) appears to allow some customization of options such as the integration algorithm and step size and data logging.

Figure A3: Selecting the C code generation real-time options

The engine and control system model shown in Fig. A3 will not run in real-time on a 50Mhz PC. A nonreal-time DOS executable model (generated using the “Nonreal-time Options”) will perform a “3 second” simulation run in 25 seconds of actual time using variable time step Runge-Kutta integration. Running the same model using Euler integration and a fixed time step of 1/2 millisecond reduces the simulation time to 9 seconds but with a slight loss in simulation accuracy. Real-time execution speeds should be possible on a PC based DSP board or possibly on a higher clock speed Pentium PC. The authors plan to determine the minimum platform needed for real-time execution so that hardware-in-the-loop testing can be 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)