Engine Modeling For Real-Time Control Using Simulink [PDF]

Zitiervorschau

SAE 950417

Automotive Engine Modeling for Real-Time Control Using MATLAB/SIMULINK 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:

SAE Robert Weeks John Moskwa

Phone: (412) 776-4841 (847) 869-2023 (608) 263-2423

Robert W. Weeks Modular Systems

Internet:

John J. Moskwa

[email protected] http://www.simcar.com [email protected]

Powertrain Control Research Laboratory University of Wisconsin-Madison

ABSTRACT

INTRODUCTION

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-fuelinjected, 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:

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.

• • • • •

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. SAE 950417

‡ 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]. Weeks & Moskwa

3/24/95

-1-

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.

SAE 950417

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. Pin 1 Ambient Conditions

Demux

Tin

Demux1 2 Tload 3 alpha mdot_fi

Engine Variable Connector

inj_pw_deg

1 Engine Variables

spark_advance 4 Actuator Outputs

Demux mdot_egri mdot_IAC Demux

Mean Torque SFI Engine

Figure 2: Engine block (from Fig. 1) *

Vectors in SIMULINK 1.3 are normally shown as thick lines in block diagrams. Weeks & Moskwa

3/24/95

-2-

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.

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

SA_cmd

spark_adv Mux

1 in_1

2 in_2

Exhaust Gas Oxygen Sensor

Throttle Position Sensor

1 out_1

5 in_5

Baro Sensor

5 out_5

2 out_2

6 in_6

6 out_6 Manifold Absolute Pressure Sensor

3 out_3

7 in_7

7 out_7

4 out_4

8 in_8

1

Ignition System Signal Select 1 (using mux) Actuator commands

EGRvalve_cmd EGR mdot_egri Valve Mux

3 in_3

Engine Speed Sensor

Ambient Air Temperature Sensor

IAC_cmd 4 in_4

Air Mass Sensor

8 out_8

Manifold Absolute Temperature Sensor

double-click to plot sensor tables

IAC mdot_IAC Valve

2 Engine Variables

double-click to plot actuator tables

Figure 3: Sensors block (from Fig. 1)

Figure 5: Actuators 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.

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.

Digitized Inputs

Controller Variables

1 Sensor Outputs

1 Actuator Inputs Input Signal Conditioning

Control Algorithms

Output Signal Conditioning 2 Controller Variables

Figure 4: Controller block (from Fig. 1)

AFego_m 1 1 AFego alpha_m 2

2 AFexh 3 AFport

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

SAE 950417

EGRvalve3_cmd 3

4 alpha

display throttle flow rates

5 EGRfrac

EGRvalve2_cmd 4

6 EngSpeed EGRvalve1_cmd 5

7 mdot_ai 8 mdot_ao

EngSpeed_m 6

9 mdot_egri

display port flow rates

10 mdot_egro 11 mdot_fi 2 Engine Variables

Demux

IAC_cmd 7 mdot_AMS_m 8

12 mdot_fo

Demux

13 mdot_IAC

mdot_ao_est 9

14 mdot_throt

1 Controller Variables

mdot_fi_cmd 10

15 Pamb

display pressures

16 Pexh

Pamb_m 11

17 Pman 18 Tamb

Pman_m 12

19 Tcool 20 Texh

SA_cmd 13

21 Tman

Tamb_m 14

22 torq_indicated Tman_m 25

23 torq_fric_pump Demux

Save Results

Demux1

Figure 6: Data Analysis block (from Fig. 1)

Weeks & Moskwa

3/24/95

-3-

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.

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). 3 mdot_ao

2 torq_fric_pump

EngLoad

4 AFport

Friction and Pumping Torque (tbl)

6 spark_adv 1 EGRfrac

Pman 4 alpha 1 Pamb 2 Tamb 9 mdot_IAC

mdot_ai

4 15

5 mdot_fi

13

Tman 14 mdot_ao

11

AFexh

21 8

12 Mux

AFport

3

EGRfrac

5

3 Tload

mdot_egro 8 mdot_egri

9

1 AFego

6

EngSpeed

Intake Manifold

16 Exhaust Manifold

Engine Block

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). Onedimensional 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]. Leak Vacuum Leak Flow Size

4 Tamb

2 Tman Tman

1 mdot_ai

+ Sum

3 mdot_ao

1 Pman VE Air Dynamics

5 AFport

divide

Product1

3 mdot_egri 2 mdot_throt

2 alpha

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.

*

PR divide

3 EngSpeed

5 Load torque

mdot_leak

-KRepeating Sequence

1/s Integrator

22

torq_fric_pump

7 spark_adv

-K1/Je

Net torque

Figure 9: Torque Production block

20

torq_indicated

Pexh 10

+

19

Texh mdot_fo

6 inj_pw_deg

Calculate Indicated Torque

2

Tcool

23

3 Pamb

torq_brake

+ Sum

17

Mux

Throttle Body

1 Pman

-

7

mdot_throt

18

1 torq_indicated

2 Pman

double-click to plot engine specific tables

* Throttle Flow

Product

P and T Correction

+ + + Sum

1 mdot_ai

4 EngSpeed

6 EGRfrac

EGR Dynamics

4 mdot_fo

2 mdot_fi and inj_pw_deg

Figure 10: Intake Manifold block (from Fig. 7)

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

SAE 950417

EGR fraction

Fuel Dynamics

5 mdot_IAC

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.

7 mdot_egro

*

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. Weeks & Moskwa

3/24/95

-4-

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]:

F GG H

I JJ K

•

FH

IK

• d T man R ⋅ Tman • − C1 ⋅ ω e ⋅ ηvol ⋅ Pman + ⋅ m ai + m egri . (1) Pman = dt Tman Vman

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).

1 Tman 4 mdot_egri

2 Pman

2 mdot_ai 3 EngSpeed

epsilon and tauf are shown as constants here but in general are time varying functions of speed, load, temperature, etc. + Sum epsilon fuel split fast fuel * Product1

fuel delay (delta t1)

mdot_fs1 slow fuel

mdot_ff3

+ + + Sum2

* Product

+ Sum1

gamma

2 EngSpeed

1 mdot_fo

mdot_ff2

2 rev delay (delta t2) if intake valve closes while fuel is injected then some fuel gets delayed two revs

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. •

•

•

•

m fo = m ff 2 + m ff 3 + m fs1

(2)

where:

LM N

•

1 Total port flow rate

•

m ff 2 = m fi

Port flow rate

•

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 − ∆T1 , 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 − ∆T2 , 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).

g

b

b t − ∆T1 g

g

FH IK IVC

b t − ∆T1 g

•

d • m fs1 = dt

R|1, γ = S Φ -Φ |T Φ

b gOP Q

⋅ε ⋅ 1− γ

•

m ff 3 = m fi

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

SAE 950417

tauf slow fuel time constant

1 mdot_fi and inj_pw_deg

3 VE

Manifold filling dynamics

b

Time varying Lag filter Slow fuel lag

m fi b t − ∆T1 g

(3) b t − ∆T2 g

⋅ε⋅γ

a f

(4) •

⋅ 1 − ε − m fs1 (5)

τf if Φ PW ≤ Φ IVC - Φ SOI

SOI

(6)

, if Φ PW > Φ IVC - Φ SOI

PW

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:

Weeks & Moskwa

3/24/95

-5-

... % 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:

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.

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

Throttle Angle (degrees)

80

• 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

70 60 50 40 30 20 10 0 0

1

2 3 Time (sec)

4

5

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.

* SIMULINK

has built-in blocks for performing table lookups that interpolate between table values. SAE 950417

Weeks & Moskwa

3/24/95

-6-

0.08

50 40

0.06

Throttle Port

0.05

Intake Port A/F

Air flow rate (kg/s)

0.07

0.04 0.03 0.02

30

20 10

0.01 0 0.5

1

1.5 2 Time (sec)

2.5

0 0.5

3

Figure 14: Throttle and intake port air flow rates

1

1.5 2 Time (sec)

2.5

3

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

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.

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.

-3

5

x 10

150

Manifold pressure (kPa)

Fuel flow rate (kg/s)

4 Injector Intake Port 3

2 1 0 0.5

1

1.5 2 Time (sec)

2.5

3

Figure 15: Injector and intake port fuel flow rates using an airmass 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.*

100 Intake Exhaust 50

0 0.5

1

1.5 2 Time (sec)

2.5

3

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.

*

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. SAE 950417

Weeks & Moskwa

3/24/95

-7-

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].

160 Indicated Friction/Pumping

140

100

-3

5

80 60 40 20 0 0.5

x 10

4

1

1.5 2 Time (sec)

2.5

3

Fuel flow rate (kg/s)

Torque (N*m)

120

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.

Injector Intake Port

3

2 1 0 0.5

1

1.5 2 Time (sec)

2.5

3

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

700

Intake Port A/F

Engine Speed (rad/s)

40 600 500

400

30

20 10

300 200 0.5

0 0.5 1

1.5 2 Time (sec)

2.5

3

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 speeddensity 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 SAE 950417

1

1.5 2 Time (sec)

2.5

3

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.

Weeks & Moskwa

3/24/95

-8-

160 Indicated Friction/Pumping

140

Torque (N*m)

120 100 80 60 40 20 0 0.5

1

1.5 2 Time (sec)

2.5

3

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

Engine Speed (rad/s)

700 600 500

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

400

% clear the workspace before starting

% define some global variables global SOItoIVC_deg aferror x0 options

300

% load vehicle specific data into workspace simspec

200 0.5

1

1.5 2 Time (sec)

2.5

3

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).

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:

* The

Levenberg-Marquardt method was originally used to identify the dynamic fuel parameters for this model from engine data on a dynamometer [3]. SAE 950417

Weeks & Moskwa

3/24/95

-9-

file name SOI0.mat SOI1.mat SOI2.mat SOI3.mat

test condition SOItoIVC_deg=0 SOItoIVC_deg=240 SOItoIVC_deg=480 SOItoIVC_deg=720

A/F ratio

A/F ratio

A/F ratio

A/F ratio

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.

50 SO ItoIVC_deg= 0 0 0.5

1

1.5

2

2.5

3

2.5

3

2.5

3

2.5

3

50 SO ItoIVC_deg= 240 0 0.5

1

1.5

2

50 SO ItoIVC_deg= 480 0 0.5

1

1.5

2

50 SO ItoIVC_deg= 720 0 0.5

1

1.5

2 Time (sec)

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

SAE 950417

Weeks & Moskwa

3/24/95

-10-

A/F ratio A/F ratio A/F ratio A/F ratio

50 epsilon= 0.00 0 0.5

1

1.5

2

2.5

3

2.5

3

2.5

3

2.5

3

2.5

3

2.5

3

2.5

3

2.5

3

50 epsilon= 0.33 0 0.5

1

1.5

2

50 epsilon= 0.66 0 0.5

1

1.5

2

50 epsilon= 1.00 0 0.5

1

1.5

2 Time (sec)

A/F ratio

A/F ratio

A/F ratio

A/F ratio

Figure 25: Effects of varying fuel split parameter, epsilon

50 tauf= 0.001 0 0.5

1

1.5

2

50 tauf= 0.11 0 0.5

1

1.5

2

50 tauf= 0.22 0 0.5

1

1.5

2

50 tauf= 0.33 0 0.5

1

1.5

2 Time (sec)

Figure 26: Effects of varying slow fuel time constant, tauf

SAE 950417

Weeks & Moskwa

3/24/95

-11-

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.

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-theloop 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. SAE 950417

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 Realtime 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 1993.

Weeks & Moskwa

3/24/95

-12-

[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]

[11]

[12]

[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.

Chang, C., Fekete, N.P. and Powell, J.D., “Engine AirFuel Ratio Control Using an Event-Based Observer,” SAE paper 930766, 1993.

[23]

McMahon, D.H., et al., “Longitudinal Vehicle Controllers for IVHS: Theory and Experiment,” in Proc. American Contr. Conf., 1992.

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..

[24]

The MathWorks, Inc., SIMULINK Accelerator User's Guide, April, 1994.

[25]

The MathWorks, Inc., SIMULINK Real-Time Workshop User's Guide, May, 1994.

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.

NOMENCLATURE

[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]

Dynamic Systems, Measurement and Control, Vol. 115 Sept. 1993.

Kao, M.H. and Moskwa, J.J., “Nonlinear Cylinder and Intake Manifold Pressure Observers for Engine Control and Diagnostics,” SAE paper No. 940375, 1994.

ADC alpha AMS AMStau C1 DSP EGR EngSpeed, ω e epsilon, ε gamma, γ IAC IVC MBT .m, m-file .mex, MEX-file •

air flow rate into intake (kg s)

mdot_ai, m ai •

mdot_ao, m ao

Amstutz, A., et al., “Model-Based Air-Fuel Ratio Control in SI Engines with a Switch-Type EGO Sensor,” SAE paper No. 940972, 1994.

mdot_egri, megri EGR flow rate into intake (kg s) •

mdot_egro, megro EGR flow rate into cylinder (kg s) •

mdot_fi, m fi mdot_fo, m fo •

mdot_ff2, m ff 2 •

mdot_ff3, m ff 3 [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). SAE 950417

air flow rate into cylinder (kg s)

•

•

[18]

analog to digital converter throttle angle (degrees) air-mass sensor air-mass sensor time constant (s) speed-density constant digital signal processor exhaust gas recirculation engine speed (rad s) fuel split parameter fraction of fuel injected before IVC idle air control intake valve close minimum spark for best torque (DBTDC) MATLAB ASCII file MATLAB object code file

•

mdot_fs1, m fs1 OBDII Pamb Pexh Pman

fuel flow rate at injector ( kg s) fuel flow rate into cylinder (kg s) fuel flow injected after IVC (kg s) fuel flow injected before IVC ( kg s) fuel flow lagged by wall wetting ( kg s) On-Board Diagnostics II ambient air pressure (kPa) exhaust manifold pressure (kPa) intake manifold pressure (kPa) Weeks & Moskwa

3/24/95

-13-

R S/D SFI SOI SOItoIVC_deg VE, ηvol Veng, Vdisp

perfect gas constant (for air R= 287 J kg °K ) speed-density sequential fuel injection start of injection Φ IVC − Φ SOI volumetric efficiency of engine (unitless) engine displacement ( m3 )

Vman tauf, τ f

intake manifold volume ( m3 ) slow fuel time constant (s)

Tamb Tman Φ SOI Φ IVC Φ PW ∆T1 , delta t1 ∆T2 , delta t2

ambient air temperature ( °K ) intake manifold temperature ( °K ) crank angle at start of injection (degrees) crank angle at intake valve close (degrees) injector pulse width in crank degrees fuel time delay from command to IVC (s) two crank revolution fuel time delay (s)

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.

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. Relative Speed 10 HP 720 8 SPARC-10 HP 710 6 Iris Indigo SPARC-2 4 IBM RS/6000, 320 This computer 2 Tadpole SPARC-1 0

0

50

100

150

200

250

Figure A1: PC’s performance (“This computer”) relative to several other computers executing the MATLAB benchmark SAE 950417

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. Weeks & Moskwa

3/24/95

-14-

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.

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 A3: Selecting the C code generation real-time options

Figure A4: Options available for real-time code generation (after selecting “Real-time Options...” in Fig A3)

SAE 950417

Weeks & Moskwa

3/24/95

-15-