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