IMPLEMENTATION OF AUTOMOBILE ENGINE

STATE DIAGNOSER ON ELECTRONIC CONTROL

UNIT FOR FAULT IDENTIFICATION
Project Report
Department of Electrical Engineering
Indian Institute of Technology, Kharagpur
Principal Investigator
Prof. Siddhartha Mukhopadhyay
Soumik Sarkar
December 2013
ii
ABSTRACT
IMPLEMENTATION OF AUTOMOBILE ENGINE STATE DIAGNOSER ON
ELECTRONIC CONTROL UNIT FOR FAULT IDENTIFICATION
Sarkar, Soumik
Department of Electrical Engineering
Principal Investigator: Prof. Siddhartha Mukhopadhyay
December 2013
Online fault identication of an auto-mobile engine is a relatively new
development that will open the doors of on-board diagnosis for engine faults, and
make the inaccessible signal proles like the pressure and temperature proles
inside the engine available to Scan Tools and Analysis Platforms. The objective
is to diagnose the internal states of an auto-mobile engine; i.e. the pressure
and temperature proles of the engine cylinder, intake manifold and exhaust
manifold. These proles, when fed to a prognoser can estimate the faults inside
the engine and hence alert the driver.
The main idea of this report is the real-time implementation of the State-
Estimating Extended Kalman Filter Diagnoser (EKFD) for on-board detection
of auto-mobile engine faults. We assume that the estimation of pressure and
temperature proles of the cylinders and manifolds of an auto-mobile engine are
the indicators of faulty behaviour of an engine. This research work is based on
previous results in this eld and this report is only concerned with the real-time
implementation of this EKFD strategy. Furthermore a benchmark model of a
typical car engine has been constructed to compare its results and to have an
overall image of how this strategy performs.
Key words: Extended Kalman Filter, Diagnoser, TargetLink, AFT
iii
TABLE OF CONTENTS
CHAPTER
1 INTRODUCTION 1
2 THEORY 3
2.1 The Plant Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Extended Kalman Filter Diagnoser . . . . . . . . . . . . . . . . . 5
3 ARCHITECTURE 7
3.1 Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Input and Output Processing . . . . . . . . . . . . . . . . . . . . 8
3.3 Diagnoser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 IMPLEMENTATION OVERVIEW 11
4.1 Model-In-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Software-In-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Changes for PIL simulation with AFT ECU . . . . . . . . . . . . 14
4.4 Processor-In-Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5 MODEL-IN-LOOP 18
5.1 Simulink model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 TargetLink model . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 TargetLink Custom Code . . . . . . . . . . . . . . . . . . 21
5.2.2 TargetLink Utility Blocks . . . . . . . . . . . . . . . . . . 25
5.2.3 TargetLink Settings . . . . . . . . . . . . . . . . . . . . . . 25
5.2.4 Autoscaling . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 SOFTWARE-IN-LOOP 30
6.1 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7 TARGETLINK AND AFT: PROCESSOR-IN-LOOP 32
7.1 ACI blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.1 AFT Utility Blocks . . . . . . . . . . . . . . . . . . . . . . 33
7.1.2 TargetLink Interface . . . . . . . . . . . . . . . . . . . . . 34
7.2 PROChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3 PROCong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4 Congurations and Hex-code generation . . . . . . . . . . . . . . 39
7.4.1 ECU Conguration . . . . . . . . . . . . . . . . . . . . . . 39
7.4.2 ACI 2 CG . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.4.3 MIL and SIL . . . . . . . . . . . . . . . . . . . . . . . . . 42
iv
7.4.4 Generate Model-Navigator Output . . . . . . . . . . . . . 42
7.4.5 Check ACI Conguration . . . . . . . . . . . . . . . . . . 42
7.4.6 Start Clear All . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4.7 Build ECU-HEX . . . . . . . . . . . . . . . . . . . . . . . 42
7.5 PROLoad and ECU details . . . . . . . . . . . . . . . . . . . . . . 45
7.6 Opal-RT Digital Simulator and PIL simulation . . . . . . . . . . . 46
7.6.1 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.6.2 Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.6.3 Development Parameters . . . . . . . . . . . . . . . . . . . 49
7.6.4 Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.6.5 Target Assignation . . . . . . . . . . . . . . . . . . . . . . 49
7.6.6 Execution Properties . . . . . . . . . . . . . . . . . . . . . 51
7.6.7 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.6.8 PIL Simulation . . . . . . . . . . . . . . . . . . . . . . . . 51
7.7 Measurement and Calibration using MARC . . . . . . . . . . . . 52
8 OBSERVATION AND RESULTS 54
9 CONCLUSION 58
REFERENCES 59
v
LIST OF FIGURES
Figure
2.1 Input, State and Measurement variables of the engine model . . . 5
3.1 Diagnoser System . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Engine-Diagnoser Loop . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 TargetLink Library . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 TargetLink Custom Code Block: Interface Tab . . . . . . . . . . . 22
5.3 TargetLink Custom Code Block: Code Tab . . . . . . . . . . . . . 22
5.4 Addle Utility used for Custom-Code . . . . . . . . . . . . . . . . 24
5.5 TargetLink Utility blocks . . . . . . . . . . . . . . . . . . . . . . . 25
5.6 TargetLink Block: Output Settings . . . . . . . . . . . . . . . . . 27
5.7 TargetLink Block: Logging and Autoscaling Settings . . . . . . . 28
5.8 TargetLink Block: RTOS Settings . . . . . . . . . . . . . . . . . . 28
5.9 Autoscale Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1 ACI Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2 AFT Utility blocks and the model subsystems . . . . . . . . . . . 33
7.3 ACI Analog In connected to input of Task Subsystem . . . . . . . 34
7.4 Inter-Task Communication . . . . . . . . . . . . . . . . . . . . . . 35
7.5 PROChange Interface . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.6 PROCong Channel Parameters Conguration . . . . . . . . . . . 37
7.7 PROCong Conguration File Generation . . . . . . . . . . . . . 39
7.8 ACI I/O parameters and conguration of the corresponding Tar-
getLink Subsystem port . . . . . . . . . . . . . . . . . . . . . . . 41
7.9 PROLoad: les to ash . . . . . . . . . . . . . . . . . . . . . . . . 45
7.10 RT-Lab: Connection . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.11 Plant Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.12 RT-Lab: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.13 RT-Lab: ML605EX1 Library . . . . . . . . . . . . . . . . . . . . . 48
7.14 RT-Lab: Development settings . . . . . . . . . . . . . . . . . . . . 49
7.15 RT-Lab: Subsystem settings . . . . . . . . . . . . . . . . . . . . . 50
7.16 RT-Lab: Execution settings . . . . . . . . . . . . . . . . . . . . . 50
7.17 MARC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.1 Cylinder Pressure . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2 Cylinder Temperature . . . . . . . . . . . . . . . . . . . . . . . . 55
8.3 Plant vs Diagnoser MIL . . . . . . . . . . . . . . . . . . . . . . . 56
8.4 Diagnoser MIL vs SIL . . . . . . . . . . . . . . . . . . . . . . . . 56
vi
8.5 Diagnoser SIL vs PIL . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.6 Plant vs Diagnoser PIL . . . . . . . . . . . . . . . . . . . . . . . . 57
1
CHAPTER 1
INTRODUCTION
The most signicant faults in the auto-mobile engines are the result of
unexpected failures, delays as well as the age of the crucial components. Also
defective internal engine equipments, in particular manifolds and valves, should
be considered. Whenever these critical situations occur; the engine could lose
control, require much more energy, and could operate harmfully. Therefore to
operate at high energy eciency and to guarantee the safety and reliability of
the engine, it is important to develop fault detection strategy, which are able
to detect and diagnose a faulty engines system components at real-time and
consequently corrective and reconguration actions could be initiated promptly.
Most of the diagnosis implementations present today are proprietary. The
present high-end diagnostics [7] are summarized as OBD-II and its equivalents in
Europe (EOBD), Australia (ADR) and Japan (JOBD). The present EOBD (Eu-
ropean On-Board Diagnostics) standard, the European equivalent of OBD-II, is
mostly concerned with Fuel and Air Metering and Auxiliary Emission Controls;
Ignition System or Misre; Vehicle Speed Controls and Idle Control System; and
Computer Control Systems. However the operators still remain implicated to
monitor some of the crucial engine performance measurements and to diagnose
the inconsistency of the engine operating equipment. Eectively the existing
methods to identify and to adjust the equipment failures are mostly labour-
intensive task, and consequently sustained, rhythmic and error-prone. In the
majority of the situations, the operators inspect the engines manually to deter-
mine the engines reaction, however they often fail to notice any faults that may
cause a future failure. Also they use special equipments, but these evaluations
still necessitate considerable human knowledge, consequently are error-prone and
could generate harsh engine operation if there is a mistake. In these circum-
stances the problem of engine monitoring and fault diagnosis becomes a critical
issue.
Therefore the objective of the research is to develop more procient, accu-
2
rate and reliable diagnoser and fault detection strategies [6] based on the non-
linear estimation techniques. An advanced Extended Kalman Filter Diagnoser
(EKFD) strategy was developed in this research and excellent preliminary results
have been obtained. In this report, the proposed EKFD strategy is model-based
and is capable to properly monitor the engine data corresponding to engines
output measurements using a reliable non-linear model. This strategy assumes
that there is a fairly accurate model that could characterize achievable system
healthy and faulty modes. This model is integrated into an Extended Kalman
Filter non-linear estimator that operates at each time instance.
The report is divided into chapters that gradually delve step-by-step into
the implementation details. This makes it easy to understand the intricacies of
the implementation detail, by having an overall understanding of all the major
steps involved in the process. Chapter 2 discusses the theory of the implementa-
tion. This is adopted from previous works in this project on this eld. Chapter
3 discusses the overall architecture of the whole system in operation, and the
design changes incorporated for implementation in an Electronic Control Unit
(ECU). Chapter 4 gives an overall and short discussion on all the implementation
steps involved in the realization process for the ECU. The next three chapters,
Chapters 5, 6, and 7 discusses the implementation steps in greater detail, empha-
sizing on each topic and providing references on each step. The implementation
details are discussed for the diagnoser model, but are true for any model that
is required to be implemented on the ECU. At last Chapter 8 summarizes the
results of the diagnoser implementation on the ECU.
3
CHAPTER 2
THEORY
2.1 The Plant Model
This section will point out some of the salient characteristics of the plant
model. The plant or the car engine considered in this research is assumed to be
a naturally aspirated four stroke SI gasoline engine consisting of the components
like air intake system, the combustion chamber (consisting of cylinder, piston)
and the exhaust system with the EGR (Exhaust Gas Recirculation) physically
connecting both the intake and exhaust systems [3]. The electronic subsystems
which controls the engine processes are fuel injector system, ignition system,
valve actuation system, etc. They, in turn, receive their actuation signals from
the Electronic Control Module (ECM) of the engine, based on the measured
sensor values.
The dynamics of engine operation is nearly periodic in terms of the ro-
tational angle of the crank-shaft over 0

C - 720

C for a 4-stroke engine, with

each stroke approximately of 180

C duration. The engine operation cycle can

broadly be divided into four major modes, namely the Intake mode, followed by
the Compression mode, the Expansion mode and nally ending in the Exhaust
mode. In each of these modes the time evolution of the engine variables are
governed by a distinct set of non-linear dynamical equation related to heat and
mass transfer. The engine dynamical modes undergo transitions in response to
events such as opening and closing of intake and exhaust valves, fuel injection,
spark ignition, etc. over the engine cycle.
A non-linear and switched dynamic model that captures non-linear and
switched dynamics of the instantaneous time evolution of the process variables
within crank angle cycles has been termed here as the Within Cycle Crank-angle-
based Model (WCCM).
The MVEM (Mean Value Engine Models), under the assumption that the
cylinder operates as a pump, describes the time evolution of averaged enthalpy
4
and mass transfers only by conventional continuous dynamical model. This sim-
plied modeling which can only capture the low frequency part of evolution of
the process variables is useful during steady state operation. Also, the large time
constant of the engine dynamics (due to volume of the manifolds, pipes, etc.)
and the sensor dynamics bring out mostly the low frequency part of the engine
process in the measured data coming from the actual engine, making MVEM
ideal for representing the low frequency response of the engine.
The WCCM of an engine in the present work comprises:
(1) The set of pressure, temperature and mass ow equations governing the
heat and mass transfer dynamics in the various modes of an engine cycle.
(2) The set of events that cause transitions from one mode of dynamics to
another.
From the governing equations it may be noted that the dynamic modes of the
engine undergo transitions and the associated set of continuous dynamical equa-
tions change not only due to control actions (e.g. valve motion, ignition) but also
due to change in operating regimes of state variables (e.g. sub-sonic or sonic,
positive ow or negative ow).
The engine dynamics has been captured in terms of a state vector dened
by temperature and pressure proles of intake manifold, exhaust manifold and
the four cylinders. The controlled inputs are given as below:
(1) Crank angle ()
(2) Throttle angle ()
(3) Angular engine speed ()
(4) Intake and exhaust valve lifts (Lv
int
) and (Lv
exh
) for each individual
cylinder.
(5) Fuel Injection Pulse Width (FUEL
PW
)
(6) EGR valve lift (L
EGR
)
The environmental inputs are ambient pressure (P
a
) and ambient temperature
(T
a
). The total number of inputs is 18 for a 4 cylinder engine. Spark advance
and combustion duration have been assumed to be known parameters.
A complete list of the inputs, states and measurements of the engine model
is given in the Figure 2.1 [6]
5
Figure 2.1: Input, State and Measurement variables of the engine model
2.2 Extended Kalman Filter Diagnoser
The dynamics of this estimator is described by the following discrete state-
space linear stochastic system obtained by linearizing the original highly nonlin-
ear system:
x
j,k+1
= A
jk
x
j,k
+B
jk
u
jk
+w
jk
y
j,k
= C
jk
x
j,k
+v
jk
where A
jk
, B
jk
, C
jk
represent the Jacobian matrices. We notice that x
j,k

R
n
- the model state could be suciently approximated by a Gaussian random
vector of x
j,k
mean and covariance matrix P
j,k|k
. The EKF state estimator of
the dynamical system consists of two phases, namely prediction and correction
phases.
Prediction Phase In this phase the current state estimate, x
j,k|k
and the state
estimate covariance, P
j,k|k
are projected forward, one step ahead, accord-
ing to:
x
j,k+1|k
= f
j
( x
j,k|k
, u
jk
)
P
j,k+1|k
= A
jk
P
j,k|k
A
T
jk
+Q
wj
and initialized by x
j,0|0
, P
j,0|0
.
Correction Phase It is a recursive computational process that consists of fol-
lowing steps:
(1) Determining the gain of the lter:
K
j,k+1
= P
j,k+1|k
C
T
jk
(C
jk
P
j,k+1|k
C
T
jk
+R
vj
)
1
(2) Once a new measurement y
j,k+1
is available, correct the vector es-
timate x
j,k|k
and the matrix elements of P
j,k|k
x
j,k+1|k+1
= x
j,k+1|k
+K
j,k+1
(y
j,k+1
h
j
( x
j,k+1|k
, u
jk
))
P
j,k+1|k+1
= (I K
j,k+1
C
jk
)P
j,k+1|k
6
The EKF estimator has only three main tuning parameters, namely P
0|0
, Q
wj
and
R
vj
. The matrices Q
wj
and R
vj
are determined by trials and errors, and incor-
porate the uncertainty in the tracking data. They have to be ne tuned because
they have a signicant contribution to make the EKF non-linear estimator more
robust. The covariance matrix P
j,k|k
gives information about the uncertainty in
the state estimate and provides an excellent criterion for the error bound.
7
CHAPTER 3
ARCHITECTURE
The diagnoser is implemented as an Extended Kalman Filter, with pre-
diction phase of the diagnoser implemented in Runge-Kutta steps. The signals
given as input to the diagnoser are measurements taken from the engine output
measurements and control inputs. The diagnoser is implemented as an array of
seven tasks, all running in parallel inside the ECU. The rst and the last task
relate to the input and output processing, respectively.
It should be noted that running one iteration of the diagnoser is very
computationally intensive. And the plant model used for simulation runs at
a sampling time of 1ms. Here, it has been assumed that taping the engine
measurements at a sampling period of 1ms will lead to a good approximation of
the engine measurements and eventually engine states. However, it was observed
that the execution time of the diagnoser far exceeds the sampling time of the
plant. Hence the diagnoser was modied to execute on a larger sampling period
with respect to the plant, by implementing a buer between the plant and the
diagnoser. The buer control system operates by capturing data, in burst mode,
from the engine measurements and storing it in the buer for further processing
by the diagnoser. The next data is captured only after all of the data in the
buer is processed by the diagnoser. Hence the buer is controlled so that the
diagnoser operates in burst mode, taking data from small instances of the engine
operating time, and diagnosing the engine states for fault identication.
3.1 Design Issues
There are some issues that is inherent in such an implementation and
the Extended Kalman Filter (EKF) algorithm. Since the EKF algorithm is a
recursive algorithm, it depends on some variables from the previous iteration
of the EKF. Some of this are the x, P matrix, and some other static variables
related to cylinder, intake manifold, and exhaust mass evolutions. Though this
8
is not an issue when the EKF operates continuously; when it operates in burst
mode, it is critical how these variables are handled when one set of data in the
buer exhausts and the data from next instance is introduced to our algorithm.
In this case, we reset the x
j,0|0
, and the static variables to reset values or initial
conditions, leaving the P matrix to the value from the previous iteration. The
reason of this arrangement is justied by the fact that the initial value of the P
matrix (P
j,0|0
) is one of the tuning parameters that denes the accuracy of the
EKF algorithm, and the value of P matrix from the previous iteration is a better
tuned value of P matrix than the initial value. Also, as we will observe in the
results, this arrangement, instead of initializing the P matrix also to its initial
value P
j,0|0
, leads to a faster convergence of estimated engine state values to its
true state values.
Another point to note about the buer control system is that since the
engine cycle is dependent on the crankangle of the engine, so the buer stores
data from engine measurements in multiples of crankangle. Hence the number
of cycles of engine data that is stored in the buer is an integral multiple of the
crankangle, and the number of continuous crankangles stored in a single burst in
the buer is critical to successful performance of diagnoser prediction and fault
detection of the algorithm. Admittedly, the diagnoser takes a nite number
of crankangle cycles for successful convergence of state estimation. Hence, an
optimal size of buer is necessary so that a true estimate of the engine state is
obtained within a single burst for successful fault detection, before the next set
of data from the next burst is obtained and processed.
Also the frequency of the crankangle varies with the throttle. Hence it is
necessary to take into consideration the entire gamut of crankangle frequencies,
so that even at the lowest frequency, we can get enough crankangle cycles inside
the buer for a single burst, for successful convergence of state estimates and a
successful fault detection.
3.2 Input and Output Processing
The input and output ports of the ECU have a xed range of valid inputs
and a xed resolution. Hence it is necessary to scale the input and output
quantities of the diagnoser, so that we can get a meaningful estimate of the
engine states. These scalings have to be manually congured, to match the
original quantities.
Apart from scaling the input, a buer is also implemented in the input
processing task. The input is sampled at a sampling interval of 1ms. However
the diagnoser takes longer than 1ms to execute each iteration of the task. Hence
9
the buer serves as a temporary storage for the data before it is fed to the
diagnoser for processing. The system is implemented in burst mode, so that
the buer stores data from a few crankangle intervals of the engine, which is
processed by the diagnoser over a longer duration, before the buer takes data
from the engine again for the next batch.
As will be evident by the end of this report, these scaling units after the
inputs and before the outputs of the ECU are most necessary for exploiting the
full range and full resolution of the ECU ports. This is necessary to match the
processor response with the expected response. However, there is also an issue
regarding future applicability of the scaled I/Os. The I/O scaling should take into
account the whole range of values that an input or output would take in future.
In absence of this exercise, the scaling can cause unexpected results if it cannot
recreate the original signal inside the ECU, in case any future signal deviates
from the range previously observed. In this report, however, this exercise is not
performed and the outputs are valid for a small subset of the engine measurement
inputs observed during the course of the project.
3.3 Diagnoser
The diagnoser is implemented in steps of ve tasks (Fig. 3.1), each de-
pendent on the previous task. Hence the total execution time of an iteration
of the entire diagnoser, is the addition of the execution times of all ve tasks.
It is possible to implement a pipelined implementation of the diagnoser, where
each task processes data from dierent engine instances, which can reduce the
overall execution time of the diagnoser to the execution time of one task. But
due to inherent loss in robustness and stability of the algorithm, the diagnoser
was implemented as serial tasks.
As has been mentioned before, the prediction phase of the diagnoser is
implemented in Runge-Kutta method. The Runge-Kutta method, often referred
to as RK4 method, is an iterative method in numerical analysis used in temporal
discretization for approximation of solutions of ordinary dierential equations.
The next value of a state variable is determined by by its present value and a
weighted average of four increments. These four increments, each of which involve
computationally intensive calculation of Jacobian matrices, are implemented in
four separate tasks.
The fth task computes the next value of the state variables using the
present value, and a weighted average of the increments from the four tasks.
Using these next values of the state variables, the correction phase of the EKF
diagnoser is also implemented as part of this task.
10
Though inside the ECU, every task is executed virtually in parallel, these
ve tasks are implemented so that in principle they execute serially, using con-
trol signals implemented inside the tasks which disable/enable a subsystem ac-
cordingly, to achieve a serial execution. Hence the execution time is a total of
execution times of each of these tasks.
Figure 3.1: Diagnoser System
11
CHAPTER 4
IMPLEMENTATION OVERVIEW
The diagnoser system implemented inside an Electronic Control Unit (ECU)
consists of input and output processing units, and the EKF diagnoser. The sys-
tem is realized in steps, rst on a PC-based modeling software for Model-In-Loop
(MIL) simulation, then by converting the system model to a C-based program-
ming language for Software-In-Loop (SIL) simulation, and nally by converting
the C-based model into machine-understandable hex codes and ashing into the
ECU for Processor-In-Loop (PIL) simulation. Some salient characteristics of the
three simulation modes and some advices on their implementation are outlined
as follows:
4.1 Model-In-Loop
The MIL simulation mode setup consists of the diagnoser system in loop
with a plant model inside a modeling tool (Fig. 4.1), in this case MATLAB 7.11.0
(R2010b) Simulink. This setup is most exible in logic and implementation, and
hence is easier to debug. The native Simulink library can be used for modeling the
system. The system can be checked with respect to its algorithmic stability and
accuracy, and should be most accurate before proceeding to the next simulation
mode.
The nal implementation in the ECU should be kept in mind while im-
plementing the system in MIL mode. It should be kept in mind that the ECU
recognizes tasks. These tasks run virtually in parallel, and are scheduled accord-
ing to predetermined priorities. Hence it is necessary to divide the algorithm
into constituent tasks and proceeding accordingly. The subsystems of a model
are mapped to tasks of the ECU. The software that does this operation is dSpace
TargetLink 3.2, which is used to generate the equivalent C-based code for the
model.
After successful and satisfactory implementation of the MIL model in
12
Figure 4.1: Engine-Diagnoser Loop
Simulink, the diagnoser in the model (only the part of the model which is re-
quired to be realized inside the ECU) is implemented using similar or equivalent
blocks in TargetLink library which is integrated with Simulink library in MAT-
LAB. These blocks help in code generation in the SIL simulation mode. Hence
this blocks contain a number of properties for code generation that should be
manually set equal to the desired properties of the nal system in the ECU.
Most important among them are datatype, scope, and scaling of the output of
the block. These properties are necessary for meeting the desired resolution of
the block output.
It should be noted that in MIL simulation mode in MATLAB Simulink
with TargetLink blocks, the TargetLink blocks are essentially Simulink blocks
with TargetLink frame (or mask) on top of them. Hence, the properties of the
TargetLink mask are ignored in MIL mode, and the properties of the underlying
Simulink block are used for simulation. The properties of the TargetLink mask
are only necessary for code generation.
Also it is important to keep in mind that the subsystems in the topmost
level of the model are replaced with TargetLink subsystems. The nested Simulink
subsystems should not be replaced with TargetLink equivalents, as this generates
an error in SIL mode. The signicance of the setting is that the compiler in SIL
mode generates a single code fragment for each TargetLink subsystem. So it tries
to integrate each nested subsystem inside the same code fragment.
Apart from the TargetLink blocks that mimic the model behaviour nec-
essary for the algorithm, there are some special purpose blocks that serve as
compiler directives for the compiler in SIL mode and need to be added inside
each subsystem inside the TargetLink subsystems. These blocks are mainly task-
related blocks that help the compiler in SIL mode to map the TargetLink sub-
systems to tasks of the ECU. This step depends on the nal implementation
13
platform of the TargetLink subsystems and hence there are several options:
a. If the nal platform of implementation (in PIL mode) is a TargetLink-based
emulation platform, the TargetLink has task blocks which can be cong-
ured to match the nal requirements. The task properties like priority
of the task, event-trigger or time-triggered nature of the task, etc. can
be congured using this block. Apart from task blocks, TargetLink also
gives the exibility to congure the scheduler, alarms, counters, and
inter-task messages too according to the requirements.
b. In this report, the nal platform of implementation (in PIL mode) is a custom
ECU by AFT, named Protronic ClassicLine. This ECU comes with its
own set of software tools, that uses the TargetLink generated code for its
task assignment, scheduling, alarms, etc. and has special blocks named
ACI (AFT Controller Interface) blocks for successful mapping. These
blocks and related settings will be discussed later in this discussion.
The TargetLink stores its settings in a .dd le attached to each model
le. The DD le (Data-Dictionary le) can be opened in the DD Manager
of TargetLink. However, manually editing the elements of the DD le is only
necessary when the OSEK settings like task, event, alarm, counter, scheduler,
messages etc. need to be explicitly dened [4]. However, since the implementa-
tion platform of this report is AFT ECU and the OSEK settings are dened by
AFT, the TargetLink DD le is not important.
4.2 Software-In-Loop
The SIL simulation mode starts with code generation for the diagnoser
which is implemented with TargetLink blocks inside TargetLink subsystems.
This C-based code is executed in loop with a Simulink based plant model to
test the diagnoser with its nite datatype and resolution, which can cause a
drain in the accuracy of the results of the diagnoser output. There can also be
instances where the simulation output diers from the desired results, even if the
system was running as desired in the MIL mode. The main causes pertaining
to this behaviour can be the datatype and resolution mismatches between the
Simulink block and its TargetLink mask.
It should also be noted that since the whole TargetLink subsystem has been
coded into an equivalent C code, it is impossible to tap the internal signals of the
TargetLink subsystem, nor is it possible to modify the properties of the block in
this mode. Hence for debugging, it is always preferable to go back to MIL mode
14
and track these mismatches in datatype and resolution, and then regenerate the
code for checking SIL mode output.
After many such iterations, when a satisfactory output is obtained, then the
next mode of simulation is PIL. However, since in this report the nal platform
of implementation is a custom ECU, there are some additional changes that need
to be incorporated.
Before discussing about these changes, it is of interest to discuss a little
about the outputs of the SIL mode of simulation. As pointed out before, the SIL
mode creates a C code for each of the TargetLink subsystems. This generated
code depends upon the settings of the TargetLink, which in turn is dependent
on the target implementation platform:
a. If the nal platform of implementation (in PIL mode) is a TargetLink-based
emulation platform, the TargetLink code generation settings have to be
set to RTOS mode, in which the code is generated in terms of tasks inside
each TargetLink subsystem. Even if tasks are not explicitly dened, the
compiler will dene a default task according to the sampling intervals
of in-ports of subsystems. The compiler tries its best to implement all
subsystems inside a top-level TargetLink subsystem inside the same task,
but all top-level TargetLink subsystems are implemented in separate
tasks.
b. As mentioned before, in this report, the nal platform of implementation
(in PIL mode) is a custom ECU by AFT. In this case, the TargetLink
code generation settings have to be set to generic C mode, in which each
top-level TargetLink subsystem is implemented in a separate C code
fragment, without any task denitions. The AFT software uses this SIL
code for implementing tasks for the ECU OS, and the process is not
user-congurable.
4.3 Changes for PIL simulation with AFT
ECU
The software package provided by AFT for conguration of the Protronic
ClassicLine ECU consists mainly of AFT PROChange, AFT PROCong 1.2.0.0,
AFT Controller Interface (ACI) 3.1.0.0, AFT PROLoad 4.0.0.0, WindRiver Diab
C Compiler 5.9.0.0 and MARC 6.0. ACI provides a controller interface around
the TargetLink subsystems which enables the ECU API (Application Program-
ming Interface) to interact with the logic in the SIL code. ACI blocks are inte-
15
grated into the Simulink library. MARC is a software environment for real-time
tracking of ECU variables and I/Os.
After successful verication of the algorithm with SIL mode, there are
some changes that need to be incorporated for PIL simulation with AFT ECU.
PROChange is used to create a new project and dene the versions of the software
tools associated with AFT ECU. PROCong is used for conguration of the
FPGA inside the ECU that caters to the input and output ports of the ECU.
The ports required by the algorithm can be dened and its properties can be
modied using this tool. Some of the most signicant properties caters to the
cut-o frequency of the lter after the inputs of the ECU, the sampling time of
the input and output ports, the push-pull conguration of the PWM outputs,
and some others. After setting these, PROCong conguration output les are
generated and there are some ACI blocks that need to be introduced to the
simulation model.
The input ACI blocks are added before each input to the rst TargetLink
subsystem, the output ACI blocks are added after each output from the last
TargetLink subsystem and the User I/O ACI blocks are added for inter-task
communication (communication between two TargetLink subsystems). Hence
every input and output of a TargetLink subsystem passes through an ACI block,
this ensures a smooth integration of the TargetLink code with the ECU API.
Apart from these, other ACI blocks like ECU conguration block, ACI cong-
uration blocks, MARC model navigator block, and Build ECU-Hex block are
added for various congurations of the ECU and its integration with the soft-
ware tools. Plus, a Task-Assignment ACI Block with the necessary task-time is
added to each TargetLink subsystem.
The ECU conguration ACI block uses the PROCong conguration out-
put les, and identies the conguration of the ECU, and its inputs and outputs.
Each of these input and output congurations are then manually mapped to each
corresponding input and output ACI block attached to the TargetLink subsys-
tems. The ACI conguration blocks map the congurations of the input and
output ECU ports, like the datatype and resolution, to the inputs and outputs
of the corresponding TargetLink subsystems. After all these changes, the SIL
code is generated to take into account the datatype and resolution changes in
the input and output ports of the TargetLink subsystems, and to check its eect
on the overall output of the ECU.
If the SIL output is satisfactory, a MARC model navigator output is gen-
erated from the model, which can be later used for navigating the model inside
the ECU using MARC. After this step, using the Build ECU-Hex block, a hex
code is generated from the ECU ACI block congurations and the TargetLink
16
SIL codes with the Diab C compiler, with task congurations from the ACI
Task-Assignment blocks inside each TargetLink subsystem. These task congu-
rations and priorities of inter-task communications are not user-congurable for
the AFT ECU.
There can be several issues with the SIL code that can lead to an error in
the build process. Some issues to consider are listed below:
Variable Name clash Same variable names in global scope can cause an error
in the build process while mapping the variables to memory locations
inside the ECU. Though the SIL code takes care of most of these naming
conventions, by naming variables after its full path from the top-level of
the model, these issues can arise due to unforeseen circumstances. These
can be easily resolved by changing the names of the variables.
TargetLink task denitions The Diab C compiler takes the task denitions
from pre-congured task denitions of the ECU and the task time from
the Task-Assignment block. Hence any task denitions generated from
TargetLink SIL causes an error in the build process. This can be resolved
by changing the code-generation mode in TargetLink settings as generic
C.
Absence of or extra Task-Assignment block Unlike TargetLink Task blocks,
there should be one and only one Task-Assignment block in each top-
level TargetLink subsystem. Any extra Task-Assignment block in any
nested subsystem will create an error.
Mismatch of ACI and TargetLink interface congurations Though the ACI
conguration blocks change the TargetLink input and output ports ac-
cording to ECU congurations (from PROCong), these can be later
changed manually, which causes an error while building the model, when
there is a mismatch of conguration between ACI block and its corre-
sponding port of TargetLink subsystem. Hence, changing the I/O port
congurations inside the TargetLink subsystems should be avoided alto-
gether.
A successful completion of the build process results in the creation of a
.s3 le and a .fpga le. These les are ashed into the Protronic ECU using
PROLoad. The .s3 le contains the internal logic of the diagnoser and the
variables linked to specic memory locations inside the ECU. The .fpga le is a
FPGA conguration le, essential for interactions between the processor and the
FPGA.
17
4.4 Processor-In-Loop
The PIL simulation mode consists of the Protronic ClassicLine custom
ECU in loop with a real-time digital simulator, in this case Opal-RT digital
simulator. As was discussed in the previous section, the code obtained from the
building the diagnoser was ashed into the ECU. The non-TargetLink part of the
model, which contains the plant model is modied into an Opal-RT compatible
model, and build into the Opal-RT memory. This model inside Opal-RT essen-
tially behaves like a real automobile engine running in real-time. The measure-
ments coming out of the model and out of Opal-RT output ports are hardwired
to the ECU inputs. The ECU outputs can be viewed using the measurement
and calibration workbench, MARC.
With all the systems in place, and execution of the both the real-time
digital simulator and the ECU in loop results in a PIL simulation. The variables
internal to the processor can be measured and calibrated using MARC, and hence
the system behaviour can be changed in real-time.
Each of these simulation modes along with steps of their implementation
are discussed in length in subsequent chapters.
18
CHAPTER 5
MODEL-IN-LOOP
Some of the characteristics of this mode of simulation were presented in sec-
tion 4.1. This chapter discusses the implementation steps in detail, and explains
the associated issues with each step.
5.1 Simulink model
First and foremost, the model with the whole loop as presented in Fig.
4.1, has to be implemented in Simulink, to test the system algorithms and their
implementation. The softwares used for this operation are MATLAB 7.11.0
(R2010b) and Simulink.
Some settings inside the Simulink environment that need to be ensured
before going ahead with running this model are listed below:
Solver (Conguration Parameters): Fixed-Step Discrete.
Tasking mode for periodic sample times (Conguration Parameters):
SingleTasking. This applies due to problems with executing TargetLink
SIL and PIL simulations with xed step solver and multitasking [4].
Workspace: The parameters used inside the Simulink model will generate an
error if the parameters are not dened. The solver searches for the values
of these parameters in Simulink, then in model workspace, and at last
in base workspace, with decreasing priority. Thus, if the value of the
parameter is dened both in model workspace and base workspace, the
model runs with the value in model workspace. Hence, it is recommended
that the parameters be dened in one of these places.
While keeping the above in mind, the whole loop with the plant model and
the diagnoser model are realised in Simulnk with blocks from Simulink general
library. Please note that the diagnoser model is a representative of any model
19
that is required to be implemented inside the ECU. All the following discussions
in this and following chapters will relate to the changes in the diagnoser for ECU
implementation. The plant model realisation is independent of the following
discussions.
It is necessary to keep the following key points in mind while realising the
diagnoser in this step of MIL:
Subsystems and Tasks: The diagnoser logic should be divided into subsys-
tems, that can be mapped into tasks. Tasks are executed parallely, while
the operations inside a task are executed serially.
Sampling Time: Subsystems with dierent sampling times generally form dif-
ferent tasks. However, if a subsystem with longer sampling time is nested
inside a subsystem with shorter sampling time, it is possible that the Tar-
getLink code will generate a code that optimizes the overall task. For
example, if a 5ms Subsystem A is nested inside a 1ms Subsystem B, then
the TargetLink SIL optimizes the code by executing the Subsystem A
every 5th iteration of Subsystem B [4]. Thus, though the sampling time
of Subsystem B is still 5ms, its execution time is reduced to 1ms. This
may not be a desirable scenario. This operation can hang the opera-
tion of the ECU, if the execution time (not the sampling time) of Task
Subsystem A is more than 1ms. Hence, it is desirable to consider this
characteristic while designing a model, to avoid surprises at the end of
the whole operation.
Datatype: This may not be a concern while realising the logic and determining
the accuracy of the model. But can be a huge factor while implementing
complex algorithms, requiring huge storage spaces for temporary, static
and state variables and big look-up tables. It should be kept in mind
that the default datatype, that Simulink assigns the outputs of its blocks,
is double. In hardware language, this datatype is equal to oat64,
meaning it occupies 64 bits of space for storing each value. Having so
much storage for each variable can ramp up the memory requirement in
case of complex algorithms. Additionally, the range of values that can be
represented with this datatype is about 1.810
+308
to 1.810
+308
. Such
a high range is not only unnecessary in most general-purpose variables,
all variables need not have such a high range. Hence, the datatypes can
be modied to the minimum size required to meet the desired range,
while maintaining the accuracy of the model.
Algorithm: It is desirable to design the ECU-realizable algorithms, right from
20
the start, as a parallel result of many smaller (with respect to complexity)
algorithms. Often an easy way to achieve this is to realise the algorithm
in terms of Simulink blocks, rather than using big code blocks of Em-
bedded MATLAB as an algorithm. Realising using Simulink blocks can
later help TargetLink to optimise the generated code by utilising any in-
herent parallelism in the algorithm. An Embedded MATLAB realisation
is more or less opaque to the TargetLink optimiser, and is straight away
used for the ECU, without optimising it for hardware implementation.
However, manually implementing an algorithm that embraces parallelism
and pipelining, is most suitable for hardware implementation.
When the diagnoser model is implemented successfully in Simulink and
the desired output is obtained, the next step is implementation of the diagnoser
model in TargetLink.
5.2 TargetLink model
The Simulink model is implemented using TargetLink Library, which has
some of the basic blocks of the Simulink library. Most other blocks in Simulink
library, which are not part of TargetLink library, can be constructed using the
basic blocks. Fig. 5.1 lists all the elements available in TargetLink library,
necessary for realization of a model in ECU.
Figure 5.1: TargetLink Library
Each of the Simulink block is replaced by either a TargetLink block or
composite TargetLink blocks that mimic its operation. Similarly, the Embedded
MATLAB code block is replaced by Custom Code Block in TargetLink simula-
tion blocks (Fig. 5.1). However, the code need formats are dierent for the two
21
blocks. The conversion of the code from Embedded MATLAB to Custom Code
in TargetLink is discussed in the following subsection.
5.2.1 TargetLink Custom Code
Before going ahead with the discussion, it is strongly recommended, that
though this section is discussed in the natural order of its occurrence, it should
not be implemented in this order. The reason for doing so is indicated at the
end of this section.
The Embedded MATLAB code is a language native to MATLAB. It can
be converted into other languages like C and C++ using tools available in MAT-
LAB. The code generated is not version dependent, hence the latest version of
MATLAB Coder is used, as it optimises the code, the most, for faster runs. The
inputs, outputs and parameters of the code block are dened according to re-
quirements of the model. The procedure for code-generation can be looked up on
the help menu of MATLAB. The recommended settings for code generation are
listed below. These settings are required for the minimum memory consumption
by the generated code and maximum user exibility. Other settings can be left
at default values and are not critical for this tutorial.
(1) Language: TargetLink Custom Code block understands C language.
Hence, the language of code generation should be C.
(2) Compiler optimization level: Switch on the optimisations for faster runs.
This greatly reduces the code generation size and time of execution.
The optimizations get better with every upcoming version of MATLAB;
hence, it is suggested that even if, the model is realized in a dierent ver-
sion of MATLAB due to compatibility issues with TargetLink, the code
be generated from the latest MATLAB version available, as it greatly
optimises the code.
(3) File partitioning: The drop-down against Generated le partitioning
method has two options, either generate one le for each MATLAB le,
or Generate all functions in same le. In this scenario, since we need to
edit the generated codes and rearrange them in TargetLink, it is better
to generate one le for each MATLAB le.
(4) Multiple code generation: Often there are situations, as was experienced
in diagnoser model, there are several Embedded MATLAB code blocks
that perform the same task on dierent inputs. Hence, most of the
functions are similar. Hence, it is advised to generate C codes for all the
22
Figure 5.2: TargetLink Custom
Code Block: Interface Tab
Figure 5.3: TargetLink Custom
Code Block: Code Tab
Embedded MATLAB codes in a model together, to avoid any duplicate
functions.
The compiler generates many les for the functions. These les can be
classied into four major types:
Type 1 the main functions (equal to the number of Embedded Matlab Codes
and named after them, e.g. DiagnoserStep1.c, DiagnoserStep2.c).
Type 2 general functions supporting execution-related functions in all the main
functions like initialization, termination, variable-type denitions, etc.
(name identies the function, e.g. Diagnoser initialize.c, Diagnoser terminate.c,
Diagnoser data.c).
Type 3 general functions supporting algorithmic functions in all the main func-
tions (named after the function they perform, e.g. sin.c, max.c).
Type 4 header les of all functions (with a .h le extension).
Now each of the Embedded MATLAB code blocks are replaced with a
TargetLink Custom-Code Block with the same name and same properties. The
custom code block has two major tabs: one for interface, and the other for
code. The interface tab as shown in Fig. 5.2 lists the inputs, outputs and the
parameters. The names and properties (discussed in subsection 5.2.3) of each
variable are dened in this tab, same as the replaced Embedded MATLAB code
block. The values of the parameters are also dened in this tab, which can be
made calibratable (subsection 5.2.3) in runtime.
After dening the interface, the code tab as shown in Fig. 5.3 lists the code
le and logging details. On pressing the Edit Custom Code button, a template
le with given File name is opened which contains sections native to TargetLink
23
Custom Code format. The sections along with the codes in each section are
discussed as follows:
p XXX/ fxp XXX: The code sections with the keywords p XXX are direc-
tives to the compiler that the code in this section of the custom code
is meant for oating-point simulations of the model. Whereas, the code
sections with the keywords fxp XXX are directives to the compiler that
the code in this section of the custom code is meant for TargetLink pro-
duction C code simulations of the model. However, if the option that
Use production code for oating-point simulation is selected, the code
in fxp XXX section and hence, the production code is needed only, so
there is no need to use the p XXX sections. Hence, in the diagnoser
model only the fxp XXX sections are used.
... decl ...: This section houses the code to declare the variables, and the header
les. The variables in functions of Type 1 are added in this section.
Plus the variables in some functions of Type 2 like XXX initialize.c and
XXX terminate.c are also added in this section.
In the diagnoser model, the header les were, instead of including in
this section, were added using the Addle utility in TargetLink Utility
blocks (Fig. 5.1), because of its exibility, in the same place as the
Custom Code block as shown in gure 5.4. It also shows two dierent
ways of linking a le. One of them is used for linking the header les
(Type 4) and the other for linking the required C les (Type 2 and 3).
... header ...: This section has code that is to be placed in the header le. Due
to the presence of many header les, they were instead included to the
diagnoser model using Addle blocks, as discussed in the ... decl ...
section. Hence, this section is not used in this model.
... restart ...: This section houses the code that is necessary to initialize the
code variables and/or code I/O when the application or the code is
restarted. Due to insignicance with respect to diagnoser model and
incompatibility with the AFT compiler, this section is not used in this
model.
... init ...: This section contains the initial values of the variables. The body
of the function Diagnoser initialize.c (Type 2) is copied and pasted
inside this section, except the variable declarations (which has already
been added in the ... decl ... section), the included header les inside
24
Diagnoser initialize.c which are included using the Addle block, and
the function denition.
... output ...: This section contains the code that is evaluated for generating
the output. The body of the corresponding main function (Type 1) is
copied and pasted inside this section, except the variable declarations
(which has already been added in the ... decl ... section) and the header
les (which are included using the Addle block), and the function
denition.
... update ...: This section updates the state variables at the end of the compu-
tation (after evaluation of the output) for use in the next iteration. The
code fragments from the ... output ... section, which are not necessary
for evaluating the output and are used for updating state variables for
next iteration are cut and pasted to this section. This operation is not
essential for the desired operation of the code, but is recommended.
... terminate ...: This section contains the code fragment executed when the
simulation is stopped like clearing I/O devices. The body of Diagnoser terminate.c
(Type 2) is copied and pasted inside this section, except the variable dec-
larations (which has already been added in the ... decl ... section), the
included header les inside Diagnoser terminate.c which are included
using the Addle block, and the function denition.
Figure 5.4: Addle Utility used for Custom-Code
After successful creation of the Custom-Code, the code is built and com-
piled into an S-function using Build S-function and Compile S-Function but-
25
tons (Fig. 5.3). Even with these instruction, the code inside the custom code le
can be illogical and can create errors. Most common errors are due to missing
brackets, and unidentied functions and header les which are not added using
Addle block. Also it is not necessary to add all the Type 2,3 and 4 functions
to the Custom Code, only those which are necessary for the respective Type 1
function need to be added. The errors generated can be identied and debugged
by looking at the error log in the MATLAB command window.
A successful code generation can also create issues with the accuracy of
the outputs, due to change in inherent logic of the code. Hence, it is strongly
recommended that the Embedded MATLAB Code blocks should be left in place
and all the other Simulink blocks should be replaced with corresponding Tar-
getLink blocks; and the discussions in all the next sections and subsections until
the end the chapter should be implemented. Then, if the MIL simulation with
the Embedded MATLAB blocks in place, gives wrong simulation outputs, then
debugging can be performed on the rest of the TargetLink model. However, if
the MIL simulation with the Embedded MATLAB blocks give the expected and
accurate simulation results, then the Embedded MATLAB code blocks can be
replaced by TargetLink Custom Code blocks. Even better, instead of replacing
Embedded MATLAB code blocks, the TargetLink custom-code blocks can be
implemented parallel to them, and the I/Os can then be switched between the
two code blocks for debugging. This ensures successful debugging of TargetLink
Custom code block and the associated generated code.
5.2.2 TargetLink Utility Blocks
The TargetLink utility blocks to be added to the model are MIL Block, SIL
Block, MIL Handler, and TargetLink Main Block (Fig. 5.1). The TargetLink
Main Block, which is used to congure the settings for code generation for SIL
mode, and SIL Block, which is used to generate equivalent code for the Tar-
getLink Task Subsystems, will be discussed in detail in next chapter. The MIL
Block is used to run simulation in MIL mode. (Fig. 5.5)
5.2.3 TargetLink Settings
Figure 5.5: TargetLink Utility blocks
As its been discussed before, the
TargetLink blocks are masks on top
of Simulink blocks necessary for only
code generation, not MIL simulation.
Hence, the Simulink settings (under
mask) of the TargetLink blocks should
26
match that of the Simulink blocks in
the Simulink model. The TargetLink settings of the TargetLink blocks are
matched with those of the Simulink settings too. Some important settings that
should be specied are:
Variable Name: This setting is critical to identifying and locating a variable
inside the ECU using MARC.
Datatype: This setting is selected same as the Simulink setting. This deter-
mines the basetype of a variable and its storage size. The options range
from bool with 1 bit storage space to oat64 with 64 bits storage (Fig.
5.6).
Class: This setting determines the properties of a variable like place of storage
(RAM/ ROM), scope, volatility, constant, and others which are simi-
lar to the variable denitions used in C (Fig. 5.6). The most common
setting is Global, which is a variable with global scope, non-volatile,
and is stored in RAM. However, the other options which are important
are Static Global, Extern Global, Static Local, Cal, Static Cal,
Extern Cal, Disp, Extern Disp, Const, Static Const, Extern Const
and some others. The names are self-explanatory, same as the variable
denitions in C, except Cal and Disp. Cal, short for calibratable
variable, is a variable with a global scope, stored in ROM and is volatile.
This is used to enable online calibration of the variable value from
MARC. Disp, short for displayable/ measured variables, have global
scope, stored in RAM, and is volatile. As the name suggests, this is used
to enable measurement of the variable in runtime through MARC. It is
not necessary to remember the properties of each option, it is available in
the tool as description for each option. Also the availability of an option
depends on the type of the variable. For example, consider a gain block.
A gain blocks output variable is measurable, but not calibratable; hence,
Disp option will be available, but Cal wont. Again the gain blocks
gain variable is both measurable and calibratable and hence both Cal
and Disp are available.
Width: The width of the variable vector is should be specied or it can be left
to Simulink and TargetLink to detect by using a -1 value for width
which means it inherits the value (Fig. 5.6). However, inheriting the
width can sometimes cause problems in detection of the width; hence it
is advisable to at least specify the widths of the in-port variables of each
TargetLink Subsystem.
27
Max and Min: By default, the variables are implemented inside the ECU mem-
ory locations so that full range of the datatype is utilized. However,
often, the variable only attains a subset of the values of the datatype.
These lower and upper threshold values, within the range of values of
the datatype, are specied in the Max and Min values of the variable
(Fig. 5.6). This ensures that the TargetLink code only implements the
given range of the variable instead of the full range, hence increasing the
resolution of the variable.
Logging: This setting is the equivalent of scopes in Simulink (Fig. 5.7). The
Data to log option, when set to None does not perform any logging,
when set to Signal history plots the variable in a display after the sim-
ulation, and when set to Min/ Max values returns only the maximum
and minimum values attained by the variable for the purpose of deciding
the Max-Min setting. The availability of this setting depends on the type
of variable. For example, a constant block does not have logging setting.
Autoscaling: This setting sets if the variable can be used by the Autoscaling
tool (discussed in subsection 5.2.4) for scaling the variable.
Inter-task communication: This setting is only enabled when code genera-
tion mode in TargetLink Main Dialog is set to RTOS settings. The
option for messages helps in selecting messages used for communication
of the variable with another variable in another task. These messages are
dened in the TargetLink DD Manager [4]. Since the diagnoser model
works in Standard code generation settings, this setting is not required.
Figure 5.6: TargetLink Block: Output Settings
28
Figure 5.7: TargetLink Block: Log-
ging and Autoscaling Settings
Figure 5.8: TargetLink Block:
RTOS Settings
5.2.4 Autoscaling
This step uses the settings in the previous section for automatically com-
puting the LSB and oset values of variables. The min-max values for each
variable is used to scale the LSB and the Oset of a variable so that the required
resolution can be obtained. This tool works only on those variables for which the
Autoscaling setting is enabled. It should be noticed that the oat32 and oat64
variables are outside the purview of this tool. For such variables, just setting the
min-max values, scales the variable.
Figure 5.9: Autoscale Settings
This option is available in the TargetLink Main Dialog - Tools tab - Start
Autoscaling Tool button (Fig. 5.9). On pressing the button, the tool opens up.
At the top of the dialog box, the system scope of the autoscale should be dened.
It is the TargetLink subsystem where the autoscale needs to be performed, and
29
the naming convention is same as the naming of folders in a PC, downwards from
the top-level model name. After selecting the scope, in the Scaling tab, when
the Start autoscaling button is pressed, the autoscaling starts and assigns a LSB
and oset value for each autoscaling enabled variable in the selected subsystem.
5.3 Debugging
After all these changes, the MIL simulation can be performed with the
whole diagnoser model in TargetLink and the plant model in Simulink. If the
output is as desired, then the following discussion can be skipped to the next
SIL mode.
However, in case of NaN outputs or undesirable outputs, if an error is
generated by TargetLink or Simulink, then it can be traced back to locate the
problem. In absence of these, the logging setting can be used to plot the
variables that are suspected of being faulty. It should be kept in mind that the
Simulink scopes can also be used inside the subsystems in MIL mode, however
they display the output of the underlying Simulink blocks. The logging setting
in the variables displays the output of the blocks as, observed by TargetLink.
The common issues that result in faulty outputs are:
Saturated datatype: If the variable simulated values overshoot the range of
the datatype, the variable saturates, and gives faulty outputs.
Scope: The variable scope can be a factor in the visibility of the variables which
can aect the output of the whole model.
Custom-Code blocks: The proper operation of a custom-code block should
be ensured by comparing the outputs of a Custom-Code block with its
corresponding Embedded MATLAB code block simultaneously, so that
the implementation of the code can be debugged. A look at the eect of
the body of the sections in the custom-code, named as XXX.c, in the
generated S-function, named as XXX p.c, can help in debugging the
custom code.
Resolution Dierence: If the same signal passes through two I/O ports and
the ports have dierent LSB and Oset settings, or have dierent datatype,
this may result in undesirable behaviour of the whole system.
30
CHAPTER 6
SOFTWARE-IN-LOOP
An overview of the characteristics of this mode of simulation were presented
in section 4.2. This chapter discusses the implementation steps in detail. The SIL
mode is activated by double-clicking the SIL mode button. Pressing the button
starts the code-generation process according to the settings of the TargetLink
Main Dialog. The compiler uses the settings of each TargetLink block, set
in the MIL mode simulations, to generate an equivalent C code, that can be
implemented in the ECU. The code-generation settings which are important for
code-generation, and ensuring compatibility with AFT are listed below:
(1) Code-generation mode: The required mode is Standard. This generates
a C code equivalent in logic to the TargetLink subsystem, taking into
account all the blocks in the nested subsystems. One of the other options
is RTOS mode, which requires a separate license from TargetLink. This
mode uses all the OSEK concepts of tasks, schedulers, alarms, counters,
and messages, to generate the equivalent C code. Each of the subsystems
are converted into tasks, dened either by user explicitly or automatically
by the compiler. However, since the diagnoser model is needed to be run
on an AFT ECU and not on TargetLink emulation platforms, this option
is not chosen. Also the code generated using this option contains task
denitions, which are not compatible with AFT hex code compiler.
(2) Code-generation target settings: The required setting is Generic ANSI-
C. Since the ECU-specic options are taken care by the AFT software
packages, the TargetLink just generates a C-code equivalent of the logic
of the TargetLink subsystems.
The codes generated by the compiler are stored in a newly created TLProj
folder in the same directory, further segregated by folders named after each
TargetLink Subsystem.
31
6.1 Debugging
The code-generation can fail due to unsupported blocks inside the Tar-
getLink Subsystems. The MATLAB Command Window gives the error log that
is helpful in solving issues related to code generation. Specically, the Embedded
MATLAB code blocks used in MIL simulation should be deleted before generat-
ing code for SIL simulation.
It can so happen that the model behaves properly in MIL mode, but not
in SIL mode. This may be due to data-type, scope, max-min related issues.
Viewing a signal is one of the ways that the code can be debugged.
It should be kept in mind that in the SIL mode the C code S-functions are
executed in place of the actual models. Hence, any Scope inside the TargetLink
Subsystem will not record the signal history. The logging can be performed by
changing the Logging setting for a variable to Signal history, so that Tar-
getLink records the signal. This is also possible in the SIL mode. And if it is
desirable to use a Simulink Scope for viewing a signal, the only way is to tap the
signal and, through a temporary output port, connect it to a scope outside the
TargetLink Subsystem.
Apart from viewing a signal, viewing the code in the TLProj directory is
another way to debug any undesirable settings in the generated C-code. Admit-
tedly, there is a loss in accuracy of the model while changing from MIL mode to
SIL mode, which is evident in the output of the model. The objective should be
to minimise this loss in accuracy.
32
CHAPTER 7
TARGETLINK AND AFT:
PROCESSOR-IN-LOOP
The overview of this chapter is discussed in sections 4.3 and 4.4. This
chapter discusses the steps in detail. After successful results were obtained in
MIL and SIL mode, the model needs to be modied to make it compatible with
AFT interface, and hence generate the machine-understandable code for suc-
cessful PIL simulation using the AFT Protronic ClassicLine ECU. The software
packages which are necessary for this implementation were introduced in section
4.3.
7.1 ACI blocks
The ACI (or AFT Controller Interface) library (Page 76 of Software Manual[2])
is integrated with Simulink library browser in MATLAB (Fig. 7.1). The library
contains the AFT utility blocks and the I/O blocks used to interface TargetLink
subsystems.
Figure 7.1: ACI Library
33
7.1.1 AFT Utility Blocks
The AFT utility blocks (Page 71 of Software Manual[2]), with the Tar-
getLink utility blocks added before, required for modifying the TargetLink model
to make it compatible with the ECU conguration, and help in mapping the
model variables to memory locations are added in the topmost level of the model
(Fig. 7.2). Detailed discussion on each of these blocks will be undertaken in
section 7.4.
Figure 7.2: AFT Utility blocks and the model subsystems
Apart from the blocks in Fig. 7.2, the Task Assignment block found in
the TaskSpecicBlocks segment of ACI library (Fig. 7.1) should be added to
each TargetLink subsystem. By double clicking on the block the sampling time
of the TargetLink subsystem can be set. Only one such block should be present
in each TargetLink subsystem, as there can be only one sampling time for each
TargetLink Subsystem. Since each TargetLink subsystem is assigned to a task,
these subsystems are henceforth mentioned as Task Subsystems.
The task assignment options consist of periodic sampling times of 1ms,
5ms, 10ms, 20ms, and 40ms; and event triggered sampling times. Some special
event triggered task sampling times are SysIdle Task, which is evoked whenever
the system is idle and can be used for diagnostic purposes; Crank Segment (KW
segment) Task, which is evoked with every crank segment and requires Crank
Position Event ACI blocks for execution; Crank Tooth Task (KW Zahn) Task,
which also requires Crank Position Event ACI blocks. Some other functions
available in Task Assignment block are assignment of SysInit Task, which is
executed only when the ECU is initialised and SysNachlauf (ECU shutdown)
Task, which is executed only when the ECU is terminated.
34
In the diagnoser model, only periodic Task Assignment is used. Since the
maximum available task time is 40ms, it should be ensured that the complexity
of each task should be less than 40ms. Often this is not possible to predict at this
phase of the development process, but generally this leads to a failure in response
from the ECU, and the measurement workbench, MARC, does not connect to
the ECU. When such an anomaly happens, it can be due to high execution time
of the algorithm that surpasses the Task Sampling Time.
7.1.2 TargetLink Interface
The available I/O ports in the ECU is available in a hardware manual[1]
like Analog In/Out ports (AI/AO), Digital In/Out ports (DI/DO), Pulse-Width
Modulated Output ports (PWM Out), etc. In the present ECU available in
the lab. (AFT PROtroniC ClassicLine), the AO is not congured. Hence it is
imperative to decide the type of ports to assign to each input and output of the
diagnoser model. Since no AO is available in the present conguration, AI were
used for inputs and PWM Out were used for outputs of the diagnoser model.
Figure 7.3: ACI Analog In connected to
input of Task Subsystem
After deciding the port type,
corresponding ACI blocks from the li-
brary are attached to the inputs of the
rst TargetLink subsystem (Fig. 7.3),
and outputs of the last TargetLink
subsystem. The Analog In block can
be found in ACI default library as
shown in Fig. 7.1, while the Pwm
Out block can be found in the Speci-
cBlocks segment of the ACI library.
Every ACI block carries a scalar sig-
nal and has a one-to-one connection with the in-ports or out-ports of a Task
Subsystem.
Thus, the input and output of the ECU is decided, however the diagnoser
model has seven Task Subsystems and the intertask communication are also
necessary for successful propagation of signals. The ACI blocks that serve the
purpose are Intertask block and SW-Variable block (Fig. 7.1). While the Inter-
task block, acting like a Rate-Transition block of Simulink, provides read-write
access to the variables of Task Subsystems and hence can be used to write the
input variables of the posterior Task Subsystem from the outputs of the ante-
rior Task Subsystem; the SW-Variable block provides read-write access to the
variables of the ECU and hence can be used to write the outputs of the anterior
35
Figure 7.4: Inter-Task Communication
Task Subsystem to some variables of the ECU and can be later retrieved from the
same variables by the inputs of the posterior Task Subsystem (Fig. 7.4). Also
it should be noted that there should always be on-to-one connection between
an ACI block and TargetLink Task Subsystem, or the ECU conguration will
generate errors.
For the diagnoser model, the User SW block or the SW-Variable block is
used, because it gives the user the exibility to dene the ECU variables by user-
dened names. It helps us to dene the name, data-type, and nature (value or
array) of an ECU variable. The scalar variables are dened with its nature set to
Value, and the vectors have nature set to Array. The only drawback is that the
array elements have to be named individually specifying the array indexes, for
example if TestArray is a vector variable with width 3, then 3 dierent variables
should be dened, named as TestArray[1], TestArray[2], and TestArray[3]. Also
note that there should be two User SW blocks containing the same variables; one
connected to the anterior Task Subsystem output, and the other connected to
the posterior Task Subsystem input, with a Zero-Order Hold attached in between
for Simulink Simulation.
The ACI help can also help in familiarising with the ACI library. Once
the addition of extra blocks for simulation is over, the model le can be closed.
7.2 PROChange
PROChange is a tool by AFT to dene the project name and its properties,
and the versions of the software packages to use with it. The detailed procedure
36
to use the tool is available in Page 32 onwards of the Software Manual [2]. An
informal procedure with the major settings are discussed in this section.
Figure 7.5: PROChange Interface
A new project can be added to
the list of projects (Fig. 7.5) by click-
ing on the menu Projects followed by
Add Project. A dialog box guides
through the steps of project creation.
It is recommended to copy the con-
tents of your project directory to a
new directory that PROChange cre-
ates. The project les are copied
to the NewProjectName/Model di-
rectory. There are compatibility issues
amongst many AFT softwares, MAT-
LAB and TargetLink. With respect to
the software package in the present lab., it should be ensured that the dSpace
TargetLink version is specied as 3.2, and that of Windriver Compiler is 5.9.0.0.
Plus since we are using MARC as the measurement and Calibration workbench,
the value for Generate A2L for Marc should be Yes. Sometimes these values
change themselves, hence it should be ensured that these values are intact even
after successful completion of the dialog box.
Then the required project should be activated before working in the project.
It is of interest to discuss a little about the new directory created by PROCong
by the name of the project name. The model les were copied by PROChange
to the subdirectory with the name Model/. All the les by Simulink and Tar-
getLink generated les are located here. The generated outputs of AFTs soft-
ware packages, like PROCong, ACI hex-code build function, etc. are store in
the outputs/ subdirectory. And the ACI hex-code build function uses the codes
in the subdirectory ApplCode/ for generating the hex code.
After ensuring that the versions of the AFT software packages are specied
correctly, and activating the present project, PROChange can be closed.
7.3 PROCong
This software is used to congure the FPGA inside the ECU for handling
the inputs and outputs of the ECU. A detailed procedure is given in Page 91
onwards of the Software Manual [2]. The ECU I/O ports that were decided
in subsection 7.1.2 are congured in this software (Fig. 7.6). For the diag-
noser model I/O, analog in channels (ADE) and switching output channels (SA)
37
Figure 7.6: PROCong Channel Parameters Conguration
should be congured. The descriptions of each conguration is also available
in the software. It is recommended to go through the manual for each of these
congurations. Also since most of the conguration names are in German, one
may need to refer a Translator along with it.
Some important congurations are listed below:
Name It is recommended that the name of the channel be changed to a name
that is identiable later (as visible in Fig. 7.6).
ADE: Conguration Parameters/ Packet/ SpeiseSpannung u16 (Analog
In) This is the conguration that species the supply voltage of the ECU.
This determines the maximum input and output voltages of the ECU
I/Os and should be specied. In this case the value is 12 Volts.
ADE: Calibration Parameters/ Channel/ FilterGrenzfrequenz u16 (Analog
In) This conguration species the limit frequency of the rst-order l-
ter after the inputs of the ECU. Setting it to the maximum value (here
18090Hz) disables the lter, and the same was done for the diagnoser
model.
ADE/SA: Signals/ Channel/ KanalInitFertig u8 (Analog In/ PWM out-
put) This conguration determines if the channel will be initialised via
a Congurator. However in diagnoser the algorithm is initialised from
the algorithm, and hence this conguration is set as nein (meaning no
in German).
SA: Conguration Parameters/ Packet/ BankBetriebsModus u8 (PWM
output) This congures the parallel and full bridge drive of the switching
38
output channels. In diagnoser model these congurations of PWM Out
were not used hence the Standard (kein PeakHold, keine Parallelschal-
tung meaning no peak hold, no parallel conguration) option was chosen.
SA: Calibration Parameters/ Channel/ LastModus u8 (PWM output) This
congures the connection of the load to the ECU. For the diagnoser,
the Low-Side seitiger Anschluss (meaning low-side connection) is used
meaning the load is connected between the ECU and SA ground. A sim-
ilar connection is reected using hard wires, and the load is connected
between the SA PWM output and the ground of the corresponding SA
bank.
SA: Calibration Parameters/ Channel/ EndstufenSchaltArt u8 (PWM
output) This congures the switching method of the PWM output. For
the diagnoser, the half-bridge operation or push/pull is used.
Task Selection (All channels) This conguration is necessary for all channels
that are used for ECU I/Os. This dialog box (as is visible in Fig. 7.6)
species the sampling times of the ECU I/Os by assigning them to the
required tasks. It is recommended to assign a task sampling time to these
ECU I/Os that is same or less than the sampling times of the TargetLink
Task subsystems that they are connected to in the model. It should be
remembered that the tasks of these channels can be dierent from the
TargetLink Task subsystems they are connected to, because PROCong
congures the ECU I/Os in the in-built FPGA, while the task of the
TargetLink Task subsystem resides in the memory, and is run in the
processor. Hence, both of them belong to dierent tasks.
After the congurations have been nalised, the conguration les are gen-
erated by going to the menu Generate followed by Generate..., which opens a
dialog box (Fig. 7.7). Pressing next generates the les, which will be used by
the ECU conguration (Fig. 7.2), for conguring the ACI blocks in the ECU.
On failure of the code generation process, re-generating the les, by pressing
next again, often resolves the error.
All these settings can be saved in a .dfc le and stored in the model
directory for future reference. Any future changes can be done on and the con-
guration les can be generated from this .dfc le. Now the software PROCong
can be closed and the model le is opened to congure the model for the ECU.
39
Figure 7.7: PROCong Conguration File Generation
7.4 Congurations and Hex-code generation
The model containing the diagnoser and plant model is opened, and the
sequence of AFT Utility blocks on the top-level (Fig. 7.2) will be used to cong-
ure the diagnoser model for the ECU. Each of the steps involved in the process
are discussed in the following subsections. It should be ensured that the errors
in each subsection should be resolved before skipping to the next subsection, as
all of them are interlinked.
7.4.1 ECU Conguration
On double-clicking the block, a dialog box opens. The code generator
type has two options TL for TargetLink and ECoder for MATLAB ECoder.
Since TargetLink is used for SIL code generation, TL is selected. The button
for checking PROChange can also be pressed if one needs to ensure that the
current project is activated and the desired versions of the software tools are
selected.
After that, the dialog box has a button labeled Apply. On pressing that,
it can be observed that the dialog box identies the correct ECU and the ECU
conguration path is identied as the location of the PROCong generated ACI
les in outputs/ directory of the current project path. Hence, the ECU cong-
uration also identies the ECU I/Os.
Hence, without closing the dialog box, each of the ACI I/O blocks (Fig.
7.3), which represent the ECU I/O, need to be assigned particular ECU pins.
After double clicking the ACI Analog In blocks and PWM Out blocks, a Block Pa-
rameters dialog box opens for each ACI block, and the Channel-Display Name
parameter is assigned the corresponding ECU pin. It should be noted that only
40
the channels Approved in PROCong are visible in the Block Parameters. Once
the pin is selected, the corresponding location of the pin is displayed in PinRef
parameter. Same channel cannot be assigned to more than one ACI block.
When all the input ACI blocks before the input of the rst Task Subsystem,
and all the output ACI blocks after the last Task Subsystem have been assigned
an ECU I/O pin, the OK button in the ECU conguration dialog box is pressed.
The dialog box then checks for congurations of all ACI blocks in the diagoser
model, along with the possible mismatches of the Task Assignment block setting
with the sampling times of the in-ports of the corresponding Task Subsystems.
The errors, if any, are displayed and can be corrected by identifying the source
of the error. After the errors are corrected, press Apply and OK again. Only
after successful completion of this step, the next steps are followed.
7.4.2 ACI 2 CG
On pressing this block, the software checks for similarity in congurations
(LSB and Oset) of the ACI blocks and the I/O ports of the TargetLink Task
subsystems. After checking all of such congurations, the software makes a list
of TargetLink Task Subsystem I/O ports whose LSB and Oset varies with that
of the ACI blocks they are connected to, and asks to change all of them. All of
such mismatches should be eliminated by changing all of the listed mismatches
either automatically by clicking Change All or manually by clicking each ACI
block and clicking on Copy ACI to CG. This ensures a smooth transition of
signals between the FPGA of the ECU and the model inside the processor of the
ECU.
On close scrutiny, one can view the parameters of the ACI input by pressing
the View Block Information button in the Block Parameters of each ACI block,
and match it to the in-port or out-port settings of the connected TargetLink
Subsystem. The Fig. 7.8 gives an example of this. The Signal Parameters of one
of the Analog In blocks species the range of the ACI block as 0-5V, with a xed
LSB and Oset. The settings of the connected TargetLink Subsystem In-port is
shown which lists the LSB and Oset same as that of the ACI block which is the
desired setting. The Max-Min setting of the In-port/ Out-port, however, is not
checked by the ACI 2 CG block, and hence should be ensured that it should be
within the range of the ACI block it is attached to.
This change can aect the accuracy of the model. Also since the range
and resolution of the input of the ECU is also xed, the input and output of the
ECU may need pre-processing or post-processing for exploiting these restrictions
to the fullest.
41
Figure 7.8: ACI I/O parameters and conguration of the corresponding Tar-
getLink Subsystem port
42
7.4.3 MIL and SIL
These modes are present in this sequence to check the accuracy of the model
taking into account the changes to the TargetLink model due to the ACI blocks.
First on pressing the MIL mode, the model is tested for any change in accuracy.
Then after pressing the SIL mode, the compiler generates an equivalent C code
for the model, which can again be tested for any degradation in accuracy.
Any change in accuracy may relate to the change in the range and reso-
lution of the inputs and the outputs. The pre-processing and post-processing
may be introduced with additional gain and addition blocks to bring the I/Os
to desired levels. It is recommended to scale even the I/Os within the range of
the ACI block to its full range, for achieving high resolutions.
7.4.4 Generate Model-Navigator Output
After achieving desired accuracy of the output in SIL mode with the
changed I/Os, the Model-Navigator Output is generated by double-clicking the
button. This is largely an automatic process and generates navigator output for
use by MARC.
7.4.5 Check ACI Conguration
This button checks all the ACI congurations in the diagnoser model, and
their accuracy. The errors generated in this option should be resolved by identi-
fying the source of the problem.
7.4.6 Start Clear All
This option should NOT be pressed unless the person who is debugging
is not sure about the errors generated in the previous subsections. On clearing
everything, the software clears every output related to ACI from the directories,
and the steps starting from section 7.3 have to be revisited.
7.4.7 Build ECU-HEX
On double-clicking this option, the Windriver Compiler compiles the con-
gurations and the SIL codes for generating the hex codes and linking them to
the ECU memory locations. If there are more than one tasks with the same
sampling time, AFT asks for the execution order of the tasks which should be in
order from the input to the output of the ECU.
43
On successful completion of the process several les are generated in the
ProjectName/ outputs/PROmake/ directory. The most important among them
is the ProjectName.aft le, while contains the hex codes to be ashed into the
ECU. The ProjectName.kkf le contains the model congurations for the models
interface inside the ECU with MARC.
The log le summarising the individual steps of the build process can be lo-
cated in ProjectName/ outputs/Log/logle.txt, and the errors generated, if any,
in ProjectName/ outputs/Log/errorlog.txt. Any error can be easily corrected by
identifying the source of the problem using the errorlog.txt. The log le, among
other compiler outputs, lists all the tasks with their corresponding task sampling
times, a summary of the project with the various versions of the software pack-
ages used for build, and a list of memory resources used by the built model (the
diagnoser model). The memory resource list is useful to get a measure of the
free memory resources that can be used for any future additions. It should also
be checked that no memory resource is full.
A snapshot of the logle is displayed below:
logfile.txt
### Used Tasks function sequence:
### - -1 [asw_aci_SysIdle.c]
### - -1 [asw_aci_TaskEvent01.c]
### - -1 [asw_aci_TaskEvent02.c]
### - -1 [asw_aci_TaskEvent03.c]
### - -1 [asw_aci_TaskEvent04.c]
### - -1 [asw_aci_TaskEvent05.c]
### - -1 [asw_aci_Segment.c]
### - -1 [asw_aci_TaskEvent06.c]
### - -1 [asw_aci_TaskEvent07.c]
### - -1 [asw_aci_KWZahn.c]
### - -1 [asw_aci_TaskEvent08.c]
### - 0.001 [asw_aci_T01ms.c]
### TL_diagnoser_in
### - 0.005 [asw_aci_T05ms.c]
### - 0.01 [asw_aci_T10ms.c]
### - 0.02 [asw_aci_T20ms.c]
### - 0.04 [asw_aci_T40ms.c]
### TL_diagnoser_main_1
### TL_diagnoser_main_2
### TL_diagnoser_main_3
### TL_diagnoser_main_4
### TL_diagnoser_main_5
### TL_diagnoser_out
### - InitFcn [asw_aci_SysInit.c]
44
### - TermFcn [asw_aci_SysNachlauf.c]
###
#########################################################################################
#########################################################################################
===============================================================================
Get free resources over MAP-File ...
===============================================================================
-------------------- class -/- size in byte hex -------------------------
. code:
__MEM_USED_CODE 00065b50
__MEM_FREE_CODE 00017c88
. data RAM:
__MEM_USED_RAM_DATA 00006918
__MEM_FREE_RAM_DATA 0000af00
. adaptive signals:
__MEM_USED_AS 000005d4
__MEM_FREE_AS 0000fa34
. calibratable data:
__MEM_USED_FSW_VP 00000000
__MEM_FREE_FSW_VP 0001ff00
-------------------------------------------------------------------------------
===============================================================================
Summary for project TL_DiagnozerDiv:
-------------------------------------------------------------------------------
- selected projectname: TL_DiagnozerDiv
- selected working directory: C:\Users\AEA04\Desktop\<Project Path>
- used derivate of PROtroniC SYSkernel: ClassicLINE
- used version of PROtroniC SYSkernel: 3.0.0.0
- used version of compiler: 5.9.0.0
- used version of Matlab: 7.11
- used version of TargetLink: 3.2
- used version of ACI: 3.1.0.0
- used version of CFG: 2.6.10.0
- used version of PROtools: 1.7.0.0
- used version of PROmake: 1.1.0.0
- used version of Perl: v5.12.2
- used version of PC-Lint:
- used Operating System: Windows_NT // Microsoft Windows [Version
6.1.7601]
- used project management file: C:\Users\AEA04\Desktop\<Project Path>\
Settings\CFG\pmf\PROtroniC_CCPonCAN.pmf
- syntax check with PC-Lint: inaktiv
- Pcheck with GetLintComments: inaktiv
- selected hardware sample: V1_0
- selected microcontroller target: CPU_5554_C
45
- selected processor: PPC5554
- Software has been compiled for code usage in: ROM.
- no errors found
Process of component build script make_all has been finished.
---------------------------------------------------
- ID file for project name <ProjectName> has been generated.
===========================================
End of process:
7.5 PROLoad and ECU details
The PROLoad is used to ash the generated .aft le into the ECU. The
ashing can only be done in boot mode, hence the software is also called PRO-
troniC BootLoader. The details of the process is listed in Page 251-253 and
268-269 of the Software Manual [2].
Figure 7.9: PROLoad: les to ash
On starting the PROLoad and
pressing connect, PROLoad asks the
user to start/ or restart the ECU. The
POWER ON wire of the ECU is then
disconnected from any power source
it was connected to, and then recon-
nected to the power source. This en-
sures the ECU to be restarted in boot
mode. Also one can notice that the
ECU, which normally draws a cur-
rent of around 1.15 A, in boot-mode
it draws a current of 0.83 A approx-
imately. After PROLoad identies the connection, by displaying Connected
on the dash, the Flash button is pressed which asks for the a .aft le to ash.
The ProjectName.aft le in ProjectName/ outputs/PROmake/ folder is selected,
which opens another dialog box asking for the les to be ashed (Fig. 7.9). The
.s3 le is the hex code le for the logic of the diagnoser. The .fs3 le contains
the congurations of the FPGA in the ECU, and is necessary for handling I/Os.
When the ashing completes, the ECU has to be restarted in normal mode,
by disconnecting the POWER ON wire from the power source and reconnecting
again, to run the ashed algorithm. The ECU pins and their desired connections
can be understood from the Hardware Manual [1].
46
Figure 7.10: RT-Lab: Connection
7.6 Opal-RT Digital Simulator and PIL sim-
ulation
The Opal-RT Digital Simulator is a digital simulator that simulates a model
in real-time. So far the diagnoser model was modied, and ashed into the ECU.
Now the plant model is required to be implemented and simulated in real-time.
The Opal-RT simulator is congured by a software named RT-Lab. Details
instructions for creating projects, and familiarisation of the interface of RT-Lab
can be obtained from its User-Guide [5] which can be located in a computer where
it is installed in C:/OPAL-RT/RT-LAB<version>/help/pdf/RT-LAB UG.pdf.
For this project, the RT-Lab version 10.4.14.223 is used.
7.6.1 Connection
The software RT-Lab is connected to the Opal-RT Simulator using an
ethernet cable. The target Opal-RT simulators installed are identied by their
names under the label Targets (Fig. 7.10). On starting the simulator, the
corresponding simulator is refreshed constantly, until it is identied by RT-Lab.
This project uses the OP5600 Opal-RT Simulator, and a right connection is
denoted by the Up status on the State parameter (Fig. 7.10).
47
7.6.2 Edit
A new model can be created by right clicking on Models under a project
in the project explorer (Fig. 7.12) and adding a new model. A dialog box will
guide through the steps in creation of a model. The tab with the project name
opens in the dash, which lists the steps involved in building and executing a
model. The rst step, as can be viewed in Fig. 7.12, is to Edit the diagram
of the model. Pressing this, opens a MATLAB blank window for creating the
model.
Figure 7.11: Plant Architecture
The rules for editing the
model is discussed in Page
41 of the RT-Lab User Guide
[5]. The top level of the
model (Fig. 7.11) consists of
sm plant, which contains the
plant model; ss io, which con-
sists of the I/O interface of
the Opal-RT; and sc console,
which contains various dis-
plays. The naming convention
means that sm XXXX is the
master subsystem (only one
per model), sc XXXX is the
console subsystem (only one
per model), and ss XXXX is the slave subsystem (can be more than one per
model).
The measurements from the plant model in sm plant are connected to ss io
and for display to sc console. The Opal-RT Digital Simulator contains an FPGA
that is responsible for interfacing the signals in its processors to the output ports.
The name of the FPGA is ML605EX1. Its library is integrated with Simulink
library, and the blocks can be used to congure the I/O from ss io (Fig. 7.13).
The Analog Output blocks from this library are used in ss io to congure
the output of the plant model. Also the OpCtrl block of ML605EX1 is used
to load the conguration from a .bin le, that should be pasted in the model
directory (in this project, ML605 1-EX-0029-2 1 5 92-128IO-01-01.bin). This
le contains the output port number for each type of block.
48
Figure 7.12: RT-Lab: Overview
Figure 7.13: RT-Lab: ML605EX1 Library
49
Figure 7.14: RT-Lab: Development settings
7.6.3 Development Parameters
The next step is to set the development parameters. The interface (Fig.
7.14) helps in selecting the Target Platform which is QNX 6.x in this case.
Also any source les, include les, libraries, library paths, or compilers that are
required to build the model should be added in this setting for successful build
of the model.
7.6.4 Build
The next step is to build the model. The compiler, using the model and
the development settings, builds the model. Any problems in the build process
is displayed in the Display Console, and can be corrected by tracing the error,
or by nding a solution in Opal-RT site.
7.6.5 Target Assignation
The next step is to assign a hardware target to each subsystem (Fig. 7.15),
excluding the sc console, which is run in the computer. The node OP5600 has
multiple cores. Each subsystem is assigned to each core internally. The XHP
on setting, short for Extra High Performance, is recommended for a high per-
formance in the real-time behaviour of Opal-RT.
50
Figure 7.15: RT-Lab: Subsystem settings
Figure 7.16: RT-Lab: Execution settings
51
7.6.6 Execution Properties
The next step is to set the execution properties (Fig. 7.16). The Target
platform in this project is QNX 6.x. Since the output ports are used, hence the
Real-time simulation mode is hardware-synchronized. Real-time communication
link type is UDP/IP for models within the same platform (OP5600).
7.6.7 Execution
The model is now ready for executing. The next step is to Load the
model, which loads the model and associated les into the memory inside the
Opal-RT OP5600 Simulator using the ethernet connection. For executing the
model, Execute the model is clicked which starts execution of the plant model.
The model can be paused by pressing Pause the model. For stopping model
execution, Reset the model is clicked to retrieve all the les from the Opal-RT
OP5600 Simulator to the computer using the ethernet connection.
It should be noted that the State parameter in the Overview page (Fig.
7.12) is labeled Loadable, which means that this model can be loaded again
and again, without Building it everytime. Hence only when there is a change in
the diagram of the model, or the status of State changes to Non-loadable, the
model should be rebuilt.
Before going ahead with the next section, it should be ensured that the
output signal of OP5600 is desirable by tapping the signal out of the output port
and displaying in an oscilloscope.
7.6.8 PIL Simulation
Now that the plant is implemented successfully in a real-time digital sim-
ulator, and the diagnoser model is also implemented in the ECU, wires are con-
nected for interfacing the Opal-RT and the ECU. The individual ECU pins and
their corresponding OP5600 pins should be referred from the RT-Lab and the
MIL models.
After successful interconnection and connecting the grounds of ECU and
OP5600 together, both are executed together for PIL simulation. The signals
between the ECU and OP5600 can be tapped using an oscilloscope. The internal
signals of the ECU can be measured and displayed using MARC.
52
7.7 Measurement and Calibration using MARC
A detailed description and guide on MARC can be found in Page 254
of the Software Manual[2]. The manual discusses setting up of the General
Conguration and other settings. The interface of MARC looks like Fig. 7.17.
A new conguration can be loaded from the menu item Devices->ECU
followed by Load Conguration. The respective .kkf le can be found in the
ProjectName/ outputs/PROmake/ directory of the project.
The Status display has a button named ECU Read info which is essential
for detecting if the ECU is running or is hanging. A successful run of the ECU
returns all the display parameters in the Status display. If the ECU is hanging,
MARC will not be able to extract any displayable parameters. This is an indica-
tion that maybe the execution time of some or all tasks is more than its sampling
time. In this scenario, building the model again using a Task Assignment block
setting with a longer sampling time may solve the problem.
On the right side of Fig. 7.17 the three important drop-down menus can
be seen, the Adjustment parameters, the Channels, and the A2L Measurements.
The Adjustment parameters drop-down contains the signals which are calibrat-
able. This includes the ECU FPGA calibratable parameters (like the ADE Filter-
Grenzfrequenz, the SA LastModus, etc.) as well as the variables in the diagnoser
model that are in Cal scope. The values can be changed by double-clicking on
the required signal.
The A2L Measurements drop-down contains the measurable signals. It
contains the I/O signals of the ECU FPGA, and the variables in the diagnoser
model in Disp scope. The signals which are required to be measured should
added to the Measurement Server (on the left of Fig. 7.17) by clicking on the
green tick beside the variable name. All those signals that are measured should
be decided before starting the measurement. All those signals that will be mea-
sured in the present session can be found in the Channel drop-down.
For starting the measurement or calibration, the red status bars with o
written on them in Fig. 7.17 can be clicked to start measuring or calibrating.
On starting their color changes to green with On written on top. On clicking
it again measurement or calibration can be stopped.
The settings of MARC conguration can be changed using the menu item
Devices->ECU followed by Open Conguration dialog (Fig. 7.17). The im-
portant settings are the measurement period, sampling interval of the measure-
ment, and baud rate of the interface. If the simulation is run long enough that
the measurement period is exhausted, MARC removes all the previous data and
starts measuring afresh without notifying. Hence, it should be ensured that the
53
Figure 7.17: MARC Interface
measurement period is long enough and the measurement is switched o before
the period exhausts. Hence, it is recommended that while the simulation is run-
ning and the measurement is on, the timestamp value should be tracked (as the
Timestamp dialog box in Fig. 7.17) and the measurement should be stopped
before the measurement period exhausts.
The Channel drop-down lists the measuring set Temp with bytes occupied
by the measured signals (Fig. 7.17). There is an upper bound to the maximum
bytes of measurement allowed. Also it should be ensured that a high memory
consuming measurement at a very small sampling interval should be appropriate
for the baud rate specied in the congurations dialog.
After the measurement is switched o, a dialog box opens asking for saving
the measurements. The measurements should be saved. The measurements can
also be exported by clicking on save + analysis, which opens a new dialog box
from where the measurement can be exported in FAMOS format. Now each of
the measured variables can be plotted by checking the check box opposite the
name of the variable and using inbuilt plotters. The plotter plots the checked
variables (Fig. 7.17).
54
CHAPTER 8
OBSERVATION AND RESULTS
The most signicant observation that one can imagine is that there is a
constant drop in accuracy as the design propagates from Simulink to MIL mode,
then SIL mode and lastly PIL mode. The reason is a constant degradation
in resolution of the in-ports and out-ports of the ECU. The system should be
implemented by taking care of these changes.
It was mentioned in Chapter 3 that the diagnoser is implemented in burst
mode, owing to the computational complexity of the algorithm. In this project,
the input processing unit is implemented with a sampling time of 1ms. However
the diagnoser, being computationally intensive, is implemented in 5 tasks of 40ms
sampling time each, operating serially. Hence the total sampling time of the
diagnoser algorithm inside the ECU is 200ms. It was observed that any lower
sampling time hangs the ECU and hence is not used. Though the diagnoser
output changes every 200ms, the sampling time of output processing unit is
selected as 40ms, as the longest task sampling time available in the software is
40ms.
Hence, the buer was implemented to facilitate the burst mode operation.
The buer is presently implemented with a capacity of 3000 datapoints for each
input (a total of 10 inputs). For a throttle-area input of about 2.710
4
sq.metre,
the buer can accommodate inputs for around six crankangle cycles. This is
expected to be enough for the diagnoser to settle down to the best estimate of the
true states of the plant and hence help the fault detection algorithm to determine
the presence or absence of a fault. An increase in throttle-area will cause more
crankangle cycles to be accommodated inside the same size of the buer, which
is better for the diagnoser as it gets more cycles to settle to a good estimate.
However, a decrease in throttle-area can reduce the number of crankangle cycles
in the buer, adversely aecting the diagnoser estimation. Hence, the buer
should be designed for the minimum throttle-area input possible to the diagnoser.
The result of the buer and the high execution time of the diagnoser algo-
55
Figure 8.1: Cylinder Pressure Figure 8.2: Cylinder Temperature
rithm has resulted in a slow detection of the plant states by the Diagnoser. The
gures 8.1 and 8.2 show the propagation of two plant states and that of their
corresponding estimated states from the diagnoser output. By noticing the time
scale of the signals, one can imagine the complexity of the algorithm. However,
as shown in the following gures, the implemented diagnoser estimates the plant
states with high accuracy.
The step-wise degradation in accuracy of the diagnoser response can be
seen in the gures 8.3, 8.4, 8.5. The degradation in the MIL response (Fig. 8.3)
with respect to the plant response is a result of discretisation of the diagnoser
algorithm. The MIL and SIL simulation responses are almost similar, hence
they overlap almost perfectly (Fig. 8.4). The SIL and PIL responses may vary
signicantly, based on quantisation problems inside the ECU.
However, on comparison of the time-scaled response of the plant with PIL
simulation results of the diagnoser for longer durations (Fig. 8.6), it was observed
that after the rst departure from the desired behaviour, the diagnoser settles
to the desired behaviour of the similar to the plant response. An explanation
for the rst departure is the evolution of the P matrix in the correction phase
of the EKF diagnoser. Throughout the Simulink, MIL and SIL simulations,
the plant model is executed with the diagnoser, starting from the same time
step in a personal computer. However, in PIL simulation, both the plant and
the diagnoser are located in dierent hardware locations. While the plant is
executed from the Opal-RT digital simulator, the diagnoser algorithm executes
from inside the ECU. Due to human factors, there can be a delay in time between
starting the execution of the OP5600 and the ECU. Hence, the P matrix diers
in behaviour from a computer-based simulation, but quickly settles to the desired
behaviour as is evident in Fig. 8.6.
The input and output processing units are crucial for the smooth execution
of the diagnoser inside the ECU. Hence the gain and the addition variables inside
56
Figure 8.3: Plant vs Diagnoser MIL
Figure 8.4: Diagnoser MIL vs SIL
Figure 8.5: Diagnoser SIL vs PIL
57
Figure 8.6: Plant vs Diagnoser PIL
these units for each input and output are made calibratable, and their outputs
are made displayable. This will help in changing the scaling variables for each
input in runtime, so that the signals inside the ECU matches the original signal.
Also crucial for its functioning is the scaling of the original input signals outside
the ECU to meet the input port range requirements.
58
CHAPTER 9
CONCLUSION
This report discusses the implementation details and associated issues with
respect to the diagnoser implementation. Overall an attempt has been made to
give importance to recommendations on implementation and discussions, rather
than exact steps of implementation which can be readily referred from the ref-
erences.
The implementation is part of an attempt by the project group to demon-
strate the practical applicability of such a computationally intensive algorithm
on a ubiquitous ECU which can readily integrated in an automobiles framework.
The burst-mode operation of a diagnoser may be termed as a pseudo-realtime
system or a soft-realtime system. However, in general, a fault in an automobile
engine may not aggravate a driving situation immediately, instead it gradually
worsens the pressure and temperature proles leading to future issues. Address-
ing automatic early detection of this engine fault is facilitated by this solution.
And hence it is not necessary to diagnose the engine proles in absolute real-
time. In the burst mode and for a buer size of 3000 for each input, the diagnoser
eectively processes a new set of inputs after every 10 minutes approximately,
which is sucient to identify a continuous fault that can aggravate and harm the
automobile engine.
59
LIST OF REFERENCES
[1] AFT Atlas Fahrzeugtechnik GmbH, Protronic hardware manual - mr, rev.
0.8 ed., May 2012.
[2] AFT Atlas Fahrzeugtechnik GmbH, Protronic manual, release 3.0 ed., Jan-
uary 2012.
[3] Somnath Sengupta; Siddhartha Mukhopadhyay; Alok Kanti Deb; Kallappa
Pattada; Soumen De, Hybrid automata modeling of si gasoline engines
towards state estimation for fault diagnosis, Tech. report, Indian Institute
of Technology Kharagpur; General Motors Company; General Motors India
Ltd, Dec 2011.
[4] dSPACE, Targetlink multirate modeling guide, targetlink 3.1 ed., February
2010.
[5] Opal-RT, Rt-lab user guide, version 10.4 ed.
[6] Avik Sadhu, Fault prognosis in automotive applications, Synopsis of the The-
sis to be Submitted in Partial Fullment of the Requirements for the Award
of the Degree of Master of Science (by Research), December 2013.
[7] Wikipedia, On-board diagnostics, http://en.wikipedia.org/wiki/
On-board_diagnostics, [Online; accessed 25-December-2013].