Sensors or Actuators get Stuck

Get Complete Project Material File(s) Now! »

Engine Model and Extensions

The Engine model is implemented in Matlab/Simulink. It is a phe-nomenological model, i.e. based on observations from real engines. Only a brief description of the original engine model is presented in Sec-tion 2.1, for more information see [4, 5]. The extensions described in Section 2.2 are the additions to the engine model to be able to reach the objectives.

Engine Model

The original model is a mean value engine model. The model can be described by state variables and flows. For a schematic overview of the system see Figure A.1. From the states (pressure and temperature) in control volume up, i.e. upstream, and down, i.e. downstream of a com-ponent, it is possible to calculate the flow through the component. The model is object oriented and components, e.g. compressor or turbine, can easily be replaced by newer and improved components with no or minor modifications to the model.

Extensions

To be able to simulate the engine’s emissions during ESC and ETC a few things need to be added to the original engine model. The ex-tensions are described below and are a small part of the software of a Scania ECU, a model of the emissions NOx and smoke, a model of the engine torque and a model for testcell control.

Engine Control Unit

Because one of the objectives is to see how faults affect the emissions, there is a need to include in the model the variables, controlled by the ECU, that have a major impact on the engine’s emissions. The variables are the injection angle α, amount of injected fuel δ and EGR valve opening controlling the amount of exhaust gas recirculated into the inlet manifold, see below for further information. One way is to integrate the wanted parts of the software of an ECU into the model. The ECU software discussed here is written in C-code.
In Simulink there is a built-in block called an S-function block that allows existing C-code to be incorporated into the Simulink model. A C-file needs to be written for that block which defines the block’s parameters, i.e. the number of inputs, number of outputs, etc. From that C-file, interaction with any other C-files is possible, e.g. the ECU’s files. Another choice is to use the ECU hardware, but that can lead to a lot of extra work.
The ECU software can consist of approximately 100 C-files and their corresponding header file. A C-file and its header file is called a module. Not all of them are needed to get the desired outputs. Also, if all of the software is included into the model the simulation time is increased.
It is desirable that no changes are made to the ECU software. There are more than one reason for this. If the C-files are out of date and have to be replaced by newer files the changes have to be done all over again. Altering the files also makes it easy to make mistakes, changing the function of the code in the files.
To avoid having to make changes to the software a C-file has to be written, which deals with the broken communication between the files used and the ones that are not used in the model. It also has to handle the fact that some sensor values are the outputs from the engine model and not the values from the usual module. For example, if one module handles the value from the engine speed sensor, every module that uses the engine speed has to be fed with the engine speed from the engine model instead. The module that handles the engine speed is now unnecessary and it can be excluded. This has to be done for every sensor value since there are no real sensors in the model. Some sensor values may not exist in the model and something else has to be done, e.g. the value may be set to a constant. The S-function block is fed with the appropriate inputs from the engine model and the outputs from the block are the calculated values by the ECU, see Figure 2.1.
Injection Angle
Injecting the fuel earlier causes the formation of NOx to increase due to higher temperature in the cylinder, but the amount of particulates decrease due to more oxidation time, see e.g. [6].
Only one module is needed to calculate the injection angle (α). This module consists of a number of look up tables. The inputs are interpolated in these tables and the logic of the module calculates α. The injection angle calculated by the ECU is an average angle for all cylinders.
Amount of Injected Fuel
The amount of fuel injected controls the entire engine. It is one of the most important parameters when developing engines.
There are a number of modules that calculate different amounts of injected fuel (δ). For example, one module calculates maximum δ allowed to avoid smoke, one for controlling δ at start up of the engine etc. The logic in a main module then decides which δ is to be the correct one. Only a few of the modules are needed for testcell driving. One calculates δ as a function of engine speed and the position of the accelerator pedal and one is used for fuel limiting, e.g. maximum allowed δ to avoid smoke or breaking the engine. The amount of fuel injected calculated by the ECU is an average amount for all cylinders.
EGR Valve
EGR lowers the combustion temperature and available oxygen therefor reducing the NOx formation. Particulates oxidation is reduced because of the lower oxygen concentration, therefor, the amount of particulates in the exhaust gases increase, see e.g. [6]. EGR is one of the concepts Scania is investigating to be able to accommodate future emission lev-els.
Three modules are needed to calculate the position of the EGR valve. One calculates the amount of exhaust gas in the inlet manifold, one gives a reference value of the amount, depending on the state of the engine, and the last one controls the EGR valve to make the calculated amount equal to the reference value.
However, at this point EGR is not included in the engine model.
No model of an EGR system is available.
Validation of the ECU Model
The ECU model was validated with a PC program called Gredi which is made by Kleinknecht. The PC is connected via an interface to the ECU hardware. Through the program and the interface it is possible to read variable and parameter values from the ECU software. This was done in a test bench were it is possible to control the sensor values e.g. engine speed, boost pressure, pedal position etc. A number of different pedal positions and engine speeds were simulated with different sensor values in the test bench and the corresponding δ and α were recorded. The same test were then done in the Simulink model.
As expected the values agreed for the major part of the test points. If the engine cooling temperature is above a certain temperature the engine will shut down to avoid the engine overheating. At situations like this the model values and the test bench values differ for obvious reasons. No fault detection is included in the ECU model.
There is no EGR system in the model. Therefor, validating the EGR valve control signal is not possible.

Emissions

Modelling of the exhaust gas emissions is very difficult. Only approx-imate models can be found. This is true especially for particulates. That is why smoke was modelled instead of particulates. Particulate matter is approximately equal to smoke plus HC. There are some cor-relation between smoke and particulate emissions. For example they both decrease when the NOx emissions increase, which is important to keep in mind when designing engines. The fact that when the NOx emission decrease the particulate emission increase and vice versa is one of the main problems when optimizing the exhaust gas emissions.
NOx and Smoke
A simple model for both smoke and NOx can be used,
Emission = a0 + a1α + a2α2, (2.1)
where, Emission = NOx or smoke a i = ai(M,N), i.e. dependent of engine torque (M) and speed (N).
To get the model to apply for most of the engine’s domain of work a number of different points with different α:s have to be executed with the engine in a test bench and the corresponding emission value recorded. It is a good idea to choose the points of the ESC. One reason is because one of the objectives is to simulate the emissions during the ESC and therefor a valid model in those points is desirable. The result becomes a function, NOx = f(α, N, M), smoke = f(α, N, M).
The coefficients ai are then fitted for each emission to give (2.1) for every point, see Figure 2.2 for NOx and Figure 2.3 for smoke, where the emission is shown as a function of injection angle for point 8 in the ESC, i.e. rpm B and 100 % load. A three dimensional look up table can be created from the equations with engine speed, torque and injection angle as inputs and the emission value as output.
Validation of the Emissions Model
For the area where the model is defined the model values are accurate. However, when faults are implemented the ECU is often outside the valid area. In these areas the model can only predict trends, i.e. if the emission is increased or decreased but not by how much. The results from the simulations must be compared with measured values before any decisions are made.

Engine Torque

When executing one of the test cycles in a testcell, the engine torque is fed back to control the engine to the work points specified in the cycle. That is why a model of the torque is needed. Tests have shown that there is a strong linear dependency between δ and the torque, see e.g. [7]. It was assumed that the torque could be modelled as M = c0 + c1δ + c2Nδ, (2.2) where ci are constants. A number of measurements from different work points of the engine can be fitted with regression analysis to (2.2) to get the value of the constants.

Testcell Control

As mentioned above when executing a test cycle a desired torque and engine speed is specified, see e.g. Table 1.2 for ESC. Different methods are adopted, to govern the engine torque to follow the reference value, depending on the cycle to be executed. For the engine speed there is an electrical engine which is fed with the desired speed and, because it is connected via a shaft to the diesel engine, the diesel engine adapts and inherits the speed. The main focus is on designing a testcell model and its control for test cycles ESC and ETC.
ESC Control
For ESC a simple PI-regulator is satisfactory to control the engine. The desired torque and engine speed are inputs to the model. The engine torque from the model is fed back and a pedal position is given, see Figure 2.5. Because the engine model stabilizes, i.e. the pressures and temperatures reach the final value, in the specified mode very fast, it is unnecessary to simulate in correct timescale, i.e. four minutes for the first step and two minutes for every else step.
ETC Control
Because there are very fast transients in ETC a simple PI-regulator is not sufficient for controlling the engine. Instead a look up table can be used with engine torque and speed as inputs and an accelerator pedal position as output, see Figure 2.6. This is to get a fast enough control over the engine. No feedback of the engine’s torque is necessary, although it has to be measured. When an ETC has been executed there are some statistical tests to validate the test cycle. Linear regression of the real values on the reference values shall be performed. Least square fit shall be used with the equation y = mx + b,
Validation of Testcell Models
An ESC was simulated and the model was able to follow the reference values. For ETC the above mentioned tests was executed after a simu-lated cycle and the statistical requirements were fulfilled. No check was done to see if the injection angle or amount of fuel injected during a simulation of these cycles was equal to measurements from a real ESC or ETC. The reason for this is that α and δ are dependent of what the sensors are showing. If the engine model is not accurate, resulting in the wrong boost pressure compared to a real engine during an ESC, α and δ will be different.

Table of contents :

1 Introduction 
1.1 Objectives
1.2 On-Board Diagnostics
1.3 European Test Cycles
1.3.1 European Stationary Cycle
1.3.2 European Transient Cycle
2 Engine Model and Extensions 
2.1 Engine Model
2.2 Extensions
2.2.1 Engine Control Unit
2.2.2 Emissions
2.2.3 Engine Torque
2.2.4 Testcell Control
3 Fault Modelling and Analysis 
3.1 Fault Modelling
3.2 Fault Simulations
3.2.1 Gain Faults
3.2.2 Bias Faults
3.2.3 Sensors or Actuators get Stuck
3.2.4 Other Faults
3.3 Fault Tree
4 Further Model Improvements 
4.1 Emissions
4.2 Torque
5 Conclusions 
Notation
A Original Engine Model
Copyright

GET THE COMPLETE PROJECT