dSPACE Emulation of a Non-Linear Model Predictive ...

Scuola Politecnica e delle Scienze di Base Corso di Laurea Magistrale in Ingegneria Informatica

Tesi di Laurea Magistrale in Analisi dei Sistemi

dSPACE Emulation of a Non-Linear Model Predictive Control Strategy for Stabilisation of an Electric Vehicle Anno Accademico 2017/2018

Relatore Prof. Sabato Manfredi Correlatore Prof. Stefano Longo

Candidato Salvatore Gariuolo matr. M63000488 I

Alla mia famiglia. A tutti coloro che in questi anni mi sono stati vicini.

II

Table of Contents Table of Contents ............................................................................................................................... III List of Figures ..................................................................................................................................... V List of Tables ................................................................................................................................... VII List of Abbreviations ...................................................................................................................... VIII Introduction ........................................................................................................................................ 11 Project Objectives .......................................................................................................................... 12 Thesis Organisation........................................................................................................................ 13 Chapter 1: Nonlinear Model Predictive Control ................................................................................ 14 1.1 History of Industrial MPC........................................................................................................ 15 1.1.1 Pre-MPC years .................................................................................................................. 15 1.1.2 Linear MPC ....................................................................................................................... 16 1.1.3 Non-Linear MPC............................................................................................................... 20 1.1.4 Latest Implementations ..................................................................................................... 20 1.2 MPC Situation Today............................................................................................................... 21 1.3 The Principle of NMPC ........................................................................................................... 24 1.2.1 Mathematical Formulation ................................................................................................ 25 1.2.2 Basic Structure .................................................................................................................. 29 1.4 NMPC as a Nonlinear Programming Problem ......................................................................... 30 Chapter 2: Model Predictive Control in the Automotive Industry..................................................... 33 2.1 Characteristics of the MPC used in the Automotive Area ....................................................... 34 2.2 MPC Applications in the Automotive Area ............................................................................. 35 2.2.1 Fuel Economy, Emissions, Thermal Management ........................................................... 35 2.2.2 Active Safety ..................................................................................................................... 38 2.2.3 Autonomous Vehicle......................................................................................................... 39 Chapter 3: Basic Characteristics of dSPACE Emulation ................................................................... 41 3.1 Testing ...................................................................................................................................... 42 3.1.1 Simulation ......................................................................................................................... 44 3.1.2 Emulation .......................................................................................................................... 45 3.1.3 Prototype Testing .............................................................................................................. 46 3.1.4 Rapid Prototyping Process ................................................................................................ 47 3.2 dSPACE SIL and HIL in the Automotive Industry ................................................................. 50 3.2.1 dSPACE Real-Time Interface ........................................................................................... 52 3.2.2 dSPACE Kernel and Scheduler......................................................................................... 53 3.2.3 dSPACE Tasks Execution Modes ..................................................................................... 57 III

3.2.4 dSPACE ControlDesk and Profiler ................................................................................... 58 3.3 NMPC Testing Activity ........................................................................................................... 59 Chapter 4: Case Study – Automotive-NMPC Design and Simulation .............................................. 60 4.1 NMPC Design .......................................................................................................................... 61 4.1.1 Vehicle Model ................................................................................................................... 61 4.1.2 Reference Generation ........................................................................................................ 64 4.1.3 MPC Strategies ................................................................................................................. 65 4.2 NMPC Simulation .................................................................................................................... 67 4.2.1 Simulation Results ............................................................................................................ 67 4.2.2 Soft-Constrained NMPC-PDIP ......................................................................................... 69 Chapter 5: Case Study – Automotive-NMPC Emulation .................................................................. 72 5.1 dSPACE Hardware – DS1005 PPC Board ............................................................................. 73 5.2 Test Plan................................................................................................................................... 75 5.3 Preliminary Activities .............................................................................................................. 76 5.3.1 dSPACE ControlDesk Employment ................................................................................. 77 5.3.2 dSPACE Profiler Employment ......................................................................................... 81 5.4 Procedure for Profiling............................................................................................................. 85 5.5 Emulation (SIL simulation) Results ......................................................................................... 87 5.5.1 Solver Execution Times .................................................................................................... 87 5.5.2 Comparison between Simulation and Emulation Results ................................................. 90 5.5.3 Further Results .................................................................................................................. 91 5.6 Benchmarking .......................................................................................................................... 92 Conclusions ........................................................................................................................................ 94 Further Work ...................................................................................................................................... 96 Appendix A: DS1005 PPC Board – Technical Details ...................................................................... 99 Appendix B: Emulation - Detailed Results ...................................................................................... 102 Appendix C: Primal-Dual Interior Point Method ............................................................................ 140 References ........................................................................................................................................ 146

IV

List of Figures Figure 1-1: Approximate genealogy of Linear MPC algorithms ...................................................... 16 Figure 1-2: Industrial use of APC methods ...................................................................................... 21 Figure 1-3: MPC applications in the US Industrial area .................................................................... 22 Figure 1-4: Receding horizon principle ............................................................................................ 28 Figure 1-5: Piecewise constant input signal ...................................................................................... 28 Figure 1-6: Basic structure of NMPC ............................................................................................... 29 Figure 2-7: Fuel consumption in 100 randomly chosen independent cases .................................... 36 Figure 2-8: Power-split HEV configuration ..................................................................................... 37 Figure 2-9: Human driver model based MPC .................................................................................. 40 Figure 3-10: Comparison of Traditional and Rapid Prototyping Development Process .................. 47 Figure 3-11: The Rapid Prototyping Development Process using Matlab/Simulink and dSPACE .. 49 Figure 3-12: dSPACE HIL System ................................................................................................... 50 Figure 3-13: ECU functions testing through dSPACE HIL Simulation ........................................... 51 Figure 3-14: Task - 3-state Model...................................................................................................... 53 Figure 3-15: Example of dSPACE scheduling ................................................................................. 55 Figure 3-16: Example of single timer task mode scheduling ............................................................ 57 Figure 3-17: Overrun situation using single timer task mode ........................................................... 57 Figure 4-18: Full-vehicle model ....................................................................................................... 61 Figure 4-19: Selection of target steady-state according to the imposed steering angle .................... 64 Figure 4-20: Velocity and Yaw rate histories for =8deg and V=Vmax+4m/s for the 3 strategies . 68 Figure 4-21: Longitudinal slips histories for =8deg and V=Vmax+4m/s for the 3 strategies ........ 68 Figure 4-22: Computational times for hard-constrained and soft-constrained NMPC-PDIP ........... 70 Figure 4-23: Time histories comparison between for the Hard and Soft constrained NMPCs (1) ........ 71 Figure 4-24: Time histories comparison between for the Hard and Soft constrained NMPCs (2) ........ 71 Figure 5-25: DS1005 PPC Board ...................................................................................................... 73 Figure 5-26: DS1005 Block Diagram ............................................................................................... 74 Figure 5-27: Selecting a project and experiment in dSPACE ControlDesk ..................................... 77 Figure 5-28: dSPACE ControlDesk – Experiment Layout ................................................................ 78 Figure 5-29: How to configure Tunable Parameters in ControlDesk – Step 1 .................................. 79 Figure 5-30: How to configure Tunable Parameters in ControlDesk – Step 2 .................................. 79 Figure 5-31: Define new Profiler event ............................................................................................. 81 Figure 5-32: Profiler – System Outputs Declaration Code ................................................................ 82 Figure 5-33: Profiler – System Output Function Execution Code ..................................................... 82 V

Figure 5-34: Profiler – System Outputs Function Exit Code ............................................................. 82 Figure 5-35: Structure of the Profiled Data ....................................................................................... 83 Figure 5-36: Structure of the Profiled Sample ................................................................................... 83 Figure 5-37: dSPACE ControlDesk Toolbar ..................................................................................... 86 Figure 5-38: dSPACE Profiler Toolbar ............................................................................................. 86 Figure 5-39: Test Case 36 - Solver Execution Time and Number of Iterations ................................ 88 Figure 5-40: Test Case 21 – Example of Outlier ............................................................................... 89 Figure 5-41: Maximum Computational Time for each Test Case ..................................................... 89 Figure 5-42: Test Case 36 – Time histories Comparison .................................................................. 90 Figure 5-43: Performance Experiments with Matrix Multiplication ................................................ 93 Figure A-44: IBM Power PC 750GX RISC Microprocessor Block Diagram ................................ 101 Figure B-45: Test Case 1 – Steering Angle = 2 degree, V = 26,24 m/s + 1 m/s ............................. 103 Figure B-46: Test Case 2 – Steering Angle = 2 degree, V = 26,24 m/s + 2 m/s ............................. 104 Figure B-47: Test Case 3 – Steering Angle = 2 degree, V = 26,24 m/s + 3 m/s ............................. 105 Figure B-48: Test Case 4 – Steering Angle = 2 degree, V = 26,24 m/s + 4 m/s ............................. 106 Figure B-49: Test Case 5 – Steering Angle = 3 degree, V = 21,4 m/s + 1 m/s ............................... 107 Figure B-50: Test Case 6 – Steering Angle = 3 degree, V = 21,4 m/s + 2 m/s ............................... 108 Figure B-51: Test Case 7 – Steering Angle = 3 degree, V = 21,4 m/s + 3 m/s ............................... 109 Figure B-52: Test Case 8 – Steering Angle = 3 degree, V = 21,4 m/s + 4 m/s ............................... 110 Figure B-53: Test Case 9 – Steering Angle = 4 degree, V = 18,51 m/s + 1 m/s ............................. 111 Figure B-54: Test Case 10 – Steering Angle = 4 degree, V = 18,51 m/s + 2 m/s ........................... 112 Figure B-55: Test Case 11 – Steering Angle = 4 degree, V = 18,51 m/s + 3 m/s ........................... 113 Figure B-56: Test Case 12 – Steering Angle = 4 degree, V = 18,51 m/s + 4 m/s ........................... 114 Figure B-57: Test Case 13 – Steering Angle = 5 degree, V = 16,54 m/s + 1 m/s ........................... 115 Figure B-58: Test Case 14 – Steering Angle = 5 degree, V = 16,54 m/s + 2 m/s ........................... 116 Figure B-59: Test Case 15 – Steering Angle = 5 degree, V = 16,54 m/s + 3 m/s ........................... 117 Figure B-60: Test Case 16 – Steering Angle = 5 degree, V = 16,54 m/s + 4 m/s ........................... 118 Figure B-61: Test Case 17 – Steering Angle = 6 degree, V = 15,07 m/s + 1 m/s ........................... 119 Figure B-62: Test Case 18 – Steering Angle = 6 degree, V = 15,07 m/s + 2 m/s ........................... 120 Figure B-63: Test Case 19 – Steering Angle = 6 degree, V = 15,07 m/s + 3 m/s ........................... 121 Figure B-64: Test Case 20 – Steering Angle = 6 degree, V = 15,07 m/s + 4 m/s ........................... 122 Figure B-65: Test Case 21 – Steering Angle = 7 degree, V = 13,93 m/s + 1 m/s ........................... 123 Figure B-66: Test Case 22 – Steering Angle = 7 degree, V = 13,93 m/s + 2 m/s ........................... 124 Figure B-67: Test Case 23 – Steering Angle = 7 degree, V = 13,93 m/s + 3 m/s ........................... 125 Figure B-68: Test Case 24 – Steering Angle = 7 degree, V = 13,93 m/s + 4 m/s ........................... 126 Figure B-69: Test Case 25 – Steering Angle = 8 degree, V = 13,01 m/s + 1 m/s ........................... 127 Figure B-70: Test Case 26 – Steering Angle = 8 degree, V = 13,01 m/s + 2 m/s ........................... 128 Figure B-71: Test Case 27 – Steering Angle = 8 degree, V = 13,01 m/s + 3 m/s ........................... 129 Figure B-72: Test Case 28 – Steering Angle = 8 degree, V = 13,01 m/s + 4 m/s ........................... 130 Figure B-73: Test Case 29 – Steering Angle = 9 degree, V = 12,24 m/s + 1 m/s ........................... 131 Figure B-74: Test Case 30 – Steering Angle = 9 degree, V = 12,24 m/s + 2 m/s ........................... 132 Figure B-75: Test Case 31 – Steering Angle = 9 degree, V = 12,24 m/s + 3 m/s ........................... 133 Figure B-76: Test Case 32 – Steering Angle = 9 degree, V = 12,24 m/s + 4 m/s ........................... 134 Figure B-77: Test Case 33 – Steering Angle = 10 degree, V =11,59 m/s + 1 m/s .......................... 135 Figure B-78: Test Case 34 – Steering Angle = 10 degree, V = 11,59 m/s + 2 m/s ......................... 136 Figure B-79: Test Case 35 – Steering Angle = 10 degree, V = 11,59 m/s + 3 m/s ......................... 137 Figure B-80: Test Case 36 – Steering Angle = 10 degree, V = 11,59 m/s + 4 m/s ........................ 138 Figure B-81: Maximum Computational Time for each Test Case................................................... 139 VI

List of Tables Table 1-1: Summary of Linear MPC application by areas ............................................................... 22 Table 1-2: Summary of Non-Linear MPC application by areas ....................................................... 23 Table 1-3: Representative NMPC simulation studies ....................................................................... 32 Table 1-4: Representative NMPC emulation studies ........................................................................ 32 Table 2-5: Comparison of MPC and GIPPS vehicles ....................................................................... 36 Table 2-6: Max. computation time of NMPC and SuboptimalMPC ............................................... 39 Table 2-7: Criteria for selecting an Evaluation Technique ............................................................... 43 Table 3-8: Required Software and Hardware to use dSPACE RTI .................................................. 52 Table 3-9: dSPACE task 3-states model ........................................................................................... 55 Table 3-10: dSPACE RTK Task-switching time .............................................................................. 56 Table 3-11: dSPACE Profiler Overhead ........................................................................................... 58 Table 4-12: Vehicle and Tyre parameters for a small sports car ...................................................... 63 Table 4-13: Computational times and performance results from the MPCs ..................................... 67 Table 5-14: Values of simState Variable .......................................................................................... 80 Table 5-15: Test Plan – Steering angle and Maximum Velocity ....................................................... 85 Table 5-16: Soft-Constrained NMPC-PDIP solver code information ............................................... 91 Table A-17: DS1005 Power PC Board – Technical Details ............................................................. 99 Table B-18: SIL Simulation Test Cases ........................................................................................... 102 Table B-19: Maximum Computational Time for each Test Case .................................................... 139

VII

List of Abbreviations

ABS

Antilock Braking System

AFS

Active Front Steering

APC

Advanced Process Control

CD

ControlDesk

CM

Center of Mass

CPU

Central Processing Unit

DMC

Dynamic Matrix Control

DOE

Design of Experiment

ECU

Electronic Control Unit

EOM

Equation Of Motion

ESC

Electronic Stability Control

FCFS

First Come First Served

FLOPS

Floating Point Operation Per Second

FPU

Floating Point Unit

HEV

Hybrid Electric Vehicle

HIL

Hardware in the Loop

HMPC

Hybrid Model Predictive Control

HW

Hardware

VIII

IDCOM

Identification and Command

IPM

Interior Point Method

ISC

Idle Speed Control

KKT

Karush-Kuhn-Tucker

LMPC

Linear Model Predictive Control

LP

Linear Programming Problem

LQG

Linear Quadratic Gaussian

LQR

Linear Quadratic Regulator

MF

Pacejka’s Magic Formula

MPC

Model Predictive Control

MPHC

Model Predictive Heuristic Control

NLP

Nonlinear Programming Problem

PDIP

Primal-Dual Interior Point

QP

Quadratic Programming

RISC

Reduced Instruction Set Computer

RM

Rate Monotonic

RMPC

Robust Model Predictive Control

RPP

Rapid Prototyping Process

RTI

Real-Time Interface

RTK

Real-Time Kernel

SIL

Software in the Loop

SQP

Sequential Quadratic Programming

SW

Software

TC

Traction Control System

IX

X

dSPACE Emulation of a Non-Linear Model Predictive Control Strategy for Stabilisation of an Electric Vehicle

Introduction

It has been about 40 years since the Dynamic Matrix Control paper [1] appeared: it caused an enthusiastic excitement in the entire world of Control Systems, starting the prosperous era of Predictive-based Controllers. In fact, Model Predictive Control (MPC), thanks to its special characteristics, has had a remarkable effect in practice, becoming one of the most used control schemas in the world. More generally, the Advanced Process Control (APC) utilisation is incredible: the industrial publication [2], published in 2005, estimates a massive APC population, composed of more than 6000 items worldwide, destined to grow even more. Instead, the web-based survey [3], published in 2008, underlines that today MPC is the most used APC in the industrial field.

The most widely used MPC is certainly Linear MPC (LMPC); this type of MPC is considerably employed in chemical and petrochemical industries, and in every area where the plant to be controlled is characterized by slow dynamics. The above-mentioned control schema uses one or more linear models to predict the system dynamics, even though many systems are inherently nonlinear. This, together with higher product quality specifications, more imposed constraints, and more demanding economic considerations [4], has induced the employment of Nonlinear MPC (NMPC). Unfortunately, NMPCs have higher computational complexity than the LMPCs, making it very difficult to employ the nonlinear predictive-based approach in all the areas, like the automotive one, where 11


processes are subject to very strict time constraints: the NMPC optimization problem must be resolved, on-line, more quickly. Nevertheless, today it is possible to employ the NMPC in several application contexts, thanks to increasing chip performance and research contribution, which introduces even more efficient approaches to solve all the NMPC issues.

One of the most interesting NMPC fields of application is undoubtedly the Automotive one: NMPC features could lead to an efficient compliance with the ever more strict constraints about fuel economy, emissions, and safety requirements.

Project Objectives The present thesis is an overview of the work carried out at the Mechatronic Laboratory of the Advanced Vehicle Engineering Centre in Cranfield University, UK. This research considers the Non-Linear Model Predictive Control (NMPC) strategy for stabilisation of an Electric Vehicle at limits of handling [5] developed at the same laboratory. The abovementioned controller, already analyzed using Simulation tests, utilizes the Primal-Dual Interior Point method as available in FORCES Pro [6] to solve the NMPC Nonlinear Programming problem. The main objectives of the thesis are:



Evaluating real-time implementabilty of the NMPC, made difficult by imposed hard real-time constraints: controller Emulation on dSPACE is employed to prove the possibility of using the NMPC in a real ECU.



Comparing Simulation and Emulation results, in order to assess the effects of the real-time hardware used for the Emulation on the NMPC performance.



Explaining all the necessary steps to test any MPC on dSPACE through Softwarein-the-Loop (SIL) simulations. 12


Thesis Organisation The Structure of the current thesis is the following:



In Chapter 1, the author conducts an extensive background research on NMPC, in order to illustrate its first application-contexts, its advantages and drawbacks, and the current open challenges. Moreover, a discussion on the NMPC as a Nonlinear Programming problem is presented.



In Chapter 2, the author gives a brief overview of the Automotive MPCs, underlining the small number of employed Emulations in their testing activity.



In Chapter 3, the author describes the Emulation as a phase of the Rapid Prototyping Process; the other phases of the process are briefly illustrated. The author also summarises the hardware and software components needed to employ a dSPACE Emulation in the Automotive industry.



In Chapter 4, the author illustrates the characteristics of control scheme [5]: the Vehicle Model and the NMPC strategy are presented, and the simulation studies carried out on the NMPC are described.



In Chapter 5, the NMPC Emulation (SIL Simulation) on dSPACE is described.

13


Chapter 1: Nonlinear Model Predictive Control Model Predictive Control (MPC), also known as moving horizon control or receding horizon control, is an Advanced Process Control (APC) strategy that uses a description of the plant to predict its behavior. At each sampling time, the MPC aims to optimize the future behavior of the plant: it computes the optimal control sequence to be sent into the plant, in order to drive the predicted output as close as possible to the reference trajectory. Nevertheless, only the first input in the optimal sequence is implemented, since the computing is restarted at successive sampling times. The optimal control sequence is computed through a calculator by minimizing an appropriate cost function subject to constraints over a future horizon: it is necessary to solve, on-line, an optimization problem. Given its characteristics, the MPCs have been employed to solve multivariable constrained control problems, typical for the petrochemical industries. Today, the landscape is totally different: MPCs are employed in many different fields, thanks to the scientific and technical progress that has allowed to fix, inter alia, some issues concerning the optimization problem.

In this chapter, the author outlines the MPC historical development in Section 1.1, and the current situation concerning the uses of the MPC in Section 1.2. Since the current project takes into consideration an NMPC, the author gives a formal description of the structure and working principle of the NMPC in Section 1.3, and he illustrates the resulting NLP problem in Section 1.4.

14


1.1 History of Industrial MPC In the scientific literature, many reviews describing the development and the historical background of the MPC [8],[9] can be found; in this section the author briefly illustrates the evolution of the MPC over time, with reference to the above-mentioned papers, where the interested reader is referred to for more details.

1.1.1 Pre-MPC years It is important to underline that the MPC belongs to the computer-based controller family, since it uses an electronic computer to calculate a set of operations, which cannot be properly computed by an analogue system due to their high complexity. Consequently, we can say that the interest in predictive-based control starts with the invention of the digital computer. Thus, we can find some of the essential features of the MPC in projects of the 40s. In spite of the potential benefits of using a calculator in a control scheme, we cannot find a wide and immediate use of this approach, because of the extremely high costs of calculators and other insurmountable limitations. We can find the first evidence of a computer-based control scheme in 1949 [10]; in 1953, M.V. Long and E.G. Holzmann [11] of Shell Development, hypothesized the use of this approach in petroleum and chemical processes. The first computer-based control schemas were implemented in various petrochemical and oil industries, including Texaco, Monsanto, etc., starting in 1959, although these installations were primarily supervisory or set-point controls.

The main idea of the MPC is to use a model of the plant into the controller: this idea sporadically appears in the literature of the 60s and early 70s. Therefore, it is so hard to establish the creator of the MPC, since it is possible to find several publications concerning MPC in the same period. In 1967 E.B.Lee e L.Markus introduced the first formal definition of MPC.

15


1.1.2 Linear MPC Linear MPC (LMPC), which is the least complex MPC, is the most widely used predictive-based control strategy in the industrial reality of the last 4 decades, due to the lack, in recent years, of computers able to calculate complex numerical elaborations. Today, it is possible to find a lot of LMPC implementations. Depending on the implemented features and their appearance times, they can be divided into 4 generations. In order to lead the reader between generations, the approximate genealogy of Linear MPC is shown in Figure 1.1.

Figure 1-1: Approximate genealogy of Linear MPC algorithms [7]

A. Linear-MPC ancestor : LQG In the early 60s, R.E. Kalman designs the Linear Quadratic Gaussian (LQG) controller [12],[13], which is the first implementation of a control algorithm based on the minimization of a cost function over a (unconstrained infinite) prediction horizon. LQG is simply the combination of a Linear Quadratic Regulator (LQR) with a Kalman filter, and these components can be independently designed and computed, according to the separation principle. Therefore, LQG control problem can be divided into two different stages: 16


at each time interval, Kalman’s filter uses the output measurement to obtain an optimal state estimate of the controlled plant, then LQR calculates the optimal input to send into the plant by minimizing a specific objective function. More specifically, the objective function used by LQG penalizes expected values of squared input and states deviations from the origin. Clearly, the plant is described by a discrete-time, linear state-space model.

LQG is considerably advantageous in many ways: (i) both Kalman’s filter gain and LQR gain can be derived from the same numerical techniques, and consequently from the same software: this obviously ensures a partial cost reduction of the whole system; (ii) the infinite prediction horizon endows the control algorithm with strong stabilizing property.Nevertheless, LQG has tiny impact on the industries, probably because of several factors [14],[15]: first of all, this control strategy does not allow to impose any constraint on the inputs, outputs, and state of the plant; consequently, LQG is not very useful, since one of the main aims of the industrial controller is to maintain the system as close as possible to its optimal operating point, and the admissible operating region of the system is defined by constraints. Other factors are: the use of an objective function which cannot be modified, the high cost of developing the ad-hoc model of the plant used in Kalman’s filter, and cultural reasons, such as the scepticism regarding this innovative technology, often regarded as impractical.

B.

Generation of Linear-MPC : IDCOM, DMC

Issues of LQG control algorithm failure statement drive the scientific community to develop a more general model-predictive-based control strategy. Since the beginning of the 70s, new control schemas are implemented: they have the same characteristics of LQG controllers and, beyond that, they are able to use any object function, and they include process input and output constraints directly into the problem, in order to prevent their violations. The statement of these control algorithms it is also possible thanks to new technologies of process identification, that allow obtaining the model of the plant to be controlled directly from measurements, reducing costs. 17


IDCOM, acronym for Identification and Command, is the software implementation of the Model Predictive Heuristic Control (MPHC) approach, that is described by Richalet et al. [14],[16] in 1976. IDCOM is also the first real implementation of the model-predictive based control strategy since: (i) input and output constraints are directly included in problem formulation, (ii) it uses a discrete-time finite impulse response model to describe the relationship between process inputs and outputs, (iii) it drives the predicted response of the plant as close as possible to a reference trajectory. Moreover, the speed of the desired closed-loop can be set by user, allowing it to adjust the algorithm aggressiveness. At the 1979 National AIChE meeting, Shell Oil engineers Cutler and Ramaker [17], presented an unconstrained multivariable control algorithm which they named DMC, an acronym for Dynamic Matrix Control. In 1980, Prett and Gilette [18] described a modified version of the DMC algorithm, in which it is possible to handle constraints and nonlinearities. The resulting algorithm is characterized by the same features of the above-described IDCOM algorithm, although in the DMC control strategy a linear step response model for the plant is used. In both implementations, a quadratic performance objective, over a finite prediction horizon, is employed.

C.

Generation of Linear-MPC : QDMC

IDCOM and DMC had a big impact in the industrial area of the 70s and 80s, even though they are almost used only on unconstrained multivariable processes, given the lack of a systematic way to implement input and output process constraints. Therefore, Engineers at Sheel Oil modify the DMC algorithm by introducing the Quadratic Programming (QP) problem, in which input and output process constraints explicitly appear; moreover, QP problem is one of the simplest possible optimization problems: the optimal solution of the problem can be easily computed using standard commercial optimization codes. This control algorithm is named QDMC and it is described by Cutler et al. [19] in 1983, and Garcìa et al. [20] in 1986. QDMC represents the second generation of LMPC.

18


D.

Generation of Linear-MPC : Multi-Objective MPC, Robust MPC

The MPC algorithms of second generation provide a systematic way to implement input and output constraints, but, despite this, they suffer from unresolved practical problems: (i) there is no clear way to handle an infeasible solution, (ii) it is extremely hard, especially for large control problems, to translate control specifications into relative weights for a single objective function (in some instances, it is even senseless to include these requirements into the same objective function, since it might not be possible to satisfy all the imposed constraints). To address the above-mentioned problems, IDCOM-M [21],[22] and SMOC [23],[24] control algorithms are developed.

Simultaneously, the first Robust MPCs (RMPC) are developed. In control theory, robust control is an approach to controller design that explicitly deals with uncertainty [25]. The management of the uncertainty is a prerequisite for efficiently controlling a system, since unexpected disturbances can appear into any physical system; moreover, the corresponding model might be affected by uncertainties. In some cases, the model uncertainties and the unexpected disturbances can be neglected. In other cases, they could cause performance degradation or, in the worst case, they can induce serious damage to the system. When you use a nonrobust MPC, a little disturbance on a state variable, close to a hard-constraint, can determine the violation of the constraint, returning an empty feasible set for the next optimization and consequently not allowing to control the system. In presence of uncertainties and disturbances is advisable to use soft-constraints that can be violated (but the violation might be as low as possible), rather than the hard constraints that cannot be violated. A soft constraint on a state variable is introduced by a slack variable that is penalized in the objective function. An optimization problem with these characteristics is named min-max problem, and it is employed in some Robust MPC [26],[27]. There are other robust implementations of the MPC control scheme, created by Lee and Yu [28], and Kothare, Balakrishnan, and Morari [29].

19


E.

Generation of Linear-MPC

Fourth generation MPC control algorithms have better improvements, such as windowsbased graphical user interfaces. 1.1.3 Non-Linear MPC Most of the real-system are inherently non-linear, so the employment of linear model to describe the plant of the NMPC is often inadequate. Nevertheless, the NMPCs are a latter implementation of the Model Predictive Control scheme: as already described in Section 1.4, the employment of non-linear model considerably complicates the MPC optimization problem, making its implementability on a real-time HW more difficult. Nowadays, the NMPC is generally used in industries thanks to more performant calculators; on the contrary, the NMPC is less used when you need to satisfy stricter constraints that introduce implementation problems. Thus, scientific literature about NMPC is less substantial than LMPC.

1.1.4 Latest Implementations Today, we witness new and more interesting Model Predictive Control implementations, such as the Hybrid MPCs (HMPC) [30], applied to systems with continuous dynamics and logical rules. Another intriguing MPC implementation is the Explicit MPC [31], [32], that off-line calculates an explicit representation of the QP problem solution, i.e. before the runtime of the process; unfortunately, these controllers currently work well only for systems with small state and input dimensions, few constraints and short time horizon [33]. Another scientific trend tries to optimize and make faster the on-line optimization through the development of new algorithms: for instance, Rao et al. [34] use the Interior-Point method to solve the QP problem.

20


1.2 MPC Situation Today The survey published in 2005 by W.M.Canney [2] estimates 6000 APC applications all over the world, and the number is expected to grow even more. Thanks to the advantages arising from its use, MPC is nowadays the most often-used APC approach, and it is a standard method in the industrial area:

Figure 1-2: Industrial use of APC methods [3]

As mentioned in the historical review of Section 1.1, MPC is considerably employed in chemical and petrochemical industries; in other application contexts, in which the plant to be controlled is characterised by faster dynamics or it is necessary to satisfy stricter time constraints, the employment of the MPC is lower, because of the computational effort required to solve the resulting control problem. According to the results of a survey conducted by ARC Advisory Group in 2005:

21


Figure 1-3: MPC applications in the US Industrial area

Also the survey conducted by S.J.Quin and T.A.Badgwell [7], that reports the count of MPC applications performed by the vendors themselves (vendors are free to define what constitute an application), highlights the situation shown in Figure 1.3:

Table 1-1: Summary of Linear MPC application by areas [7]

22


Table 1-2: Summary of Non-Linear MPC application by areas [7]

It is necessary to stress that the data reported in Tables 1.1 and 1.2 cannot be read as a statistic, since these tables do not include in-house applications performed by companies who have licensed vendor technology. Moreover, the survey draws attention to the larger employment of the LMPC than the NMPC; after all, innovative algorithms and new calculators with even more compute capability encourage today the employment of NMPC, which is significantly more beneficial than the LMPC.

23


1.3 The Principle of NMPC In 1967 E.B.Lee e L.Markus [35] introduced the following definition, which even now summarizes the essential characteristics of the MPC control strategy:

« One technique for obtaining a feedback controller synthesis from knowledge of open-loop controllers is to measure the current control process state and then compute very rapidly for the open-loop control function. The first portion of this function is then used during a short time interval, after which a new measurement of the process state is made and a new open-loop control function is computed for this measurement. The procedure is then repeated. »

Therefore, MPC is not a specific controller but a control strategy that can be used in many different ways; in fact, leaving aside the latest implementations, it is possible to identify several types of MPC depending on the model used to represent the process, the imposed constraints, and the performance index and the optimization algorithm employed. In all cases, as suggested by Lee and Markus’s explanation, the MPC uses the same distinctive working principle, named receding horizon principle.

Since one of the main aims of the project is to evaluate the real-time implementabilty of an NMPC, it is necessary to explain its basic characteristics. Therefore, the author illustrates the mathematical formulation of the NMPC and its working principle in subsection 1.3.1, and he shows its basic structure in subsection 1.3.2.

24


1.2.1 Mathematical Formulation It is important to underline that a broad variety of alternative NMPC continuous-time formulations [36],[37] and discrete-time formulations [38],[39] are available in the literature; we refer to the discrete-time mathematical formulation of the NMPC used by C.Tricaud and Y.Q.Chen in [40]. Therefore, the following discrete time-invariant nonlinear plant is considered: (

where ( )

)

( ( ) ( ))

is the state vector, ( )

(1.1)

( )

is the input, and

is a nonlinear function describing the system dynamics, with (

)

.

The system could be characterized by state noise and measurement noise, which are assumed to be Gaussian with zero mean.

In practice, processes are subject to constraints: some specific process signals must not violate bounds, due to physical restriction, environmental rules and regulations, safety limitation, etc. Besides, the control scheme should drive the process towards the constraints without violating them: generally this ensures economic benefits. In most cases, constraints can be translated in bounds on input signals, often referred to as control signals, and state signals:

( ) *

, |

( ) *

In the case of constrained system,

(1.2a) +

, |

is connected,

(1.2b)

(1.3a) +

(1.3b)

is a compact set including the origin.

The input constraints, which arise due to actuator limitations, are hard constraints because 25


they must be satisfied; the other constraints, which are generally associated with operational limitations, can be usually viewed as soft constraints because they can be violated in order to obtain a feasible optimization problem. In the optimization problem, additionally, also equality constraints are employed (usually they are motivated by the control algorithm itself). For example, the control signal is usually forced to become constant beyond control horizon

), in order to make the controller more robust:

(usually (

(1.4)

| )

We try to minimize the cost function (1.5):

( ̂(

)

)

∑ ( ̂( (

Subject to

) (

))

(1.5)

)

(1.6)

where ( ( ) ( )), that usually is a quadratic function, represents an intermediate cost on the state and control input of the process,

represent the control/prediction horizon,

and ̂ is the predicted state of the process. It is necessary to underline the distinction between real system signals and model values: this is absolutely necessary since the openloop predicted behavior of the system is not the same as the actual closed-loop behavior, even in the nominal undisturbed case. So, the main aim of NMPC is to predict the process behavior over a finite prediction horizon function over a finite control horizon

, which is used to minimize a constrained cost (the control horizon is often chosen equal to the

prediction horizon, since only in some peculiar applications its role is decisive [41]). We assume the following:

Assumption 1 : (‖( ( ) ( )‖) Where

→

( ( ) ( ))

(‖( ( ) ( )‖)

are strictly increasing functions, and

( )

( )

(1.7) . 26


Assumption 2 : )

̂( (

With

) and ̂(

) (

))

(1.8)

)

̂(

Where (

( ̂(

(1.9a) )

(1.9b)

) are the input and the predicted state at current time .

An appropriate optimization algorithm is applied to compute a sequence of future control signals that minimizes the objective function (1.5) subject to the constraints (1.2a), (1.3a). To obtain a tractable optimization problem, the input signal

( ) must be structured:

this procedure also allows to handle signal constraints and reject measurable disturbances [42]; we usually parameterize the input signal as piecewise constant function over the sampling times on the control horizon with orthogonal basis functions: the degrees of freedom in the resulting optimization problem is bounded. Like the LMPC, the NMPC uses the receding horizon principle: after the computation of the optimal control sequence ( ) over the control horizon, only the first control sample is used at time ; the horizon is then shifted by one sample and a new optimization problem, which is based on new measurements, is solved at time

. The entire working principle is summarised

in Figures 1.4 and 1.5.

An optimal sequence is assumed to exist for every initial state ( ) ( )

,

( )

(

)

(

)-

: (1.10)

If a feasible solution for the optimization problem based on (1.5), with constraints (1.6), (1.9a), (1.9b), at the initial time 0 and some horizon

exists, then the next solutions

are guaranteed to exists, since there is at least one feasible solution.

27


Figure 1-4: Receding horizon principle [4]

Figure 1-5: Piecewise constant input signal [4]

28


1.2.2 Basic Structure According to (1.5), NMPC requires measurement or estimate of the current process state, since the output prediction, obtained by solving the constrained optimization problem, depends on the state variable; it is therefore necessary, contrary to LMPC, to equip the NMPC structure of a state estimator. Additionally, a disturbance estimator can be used as well: the NMPC, like the LMPC, can exhibit steady-state offset due to unexpected and unmeasured disturbances or modeling errors [4]. This problem can be handled using a disturbance estimator which lends the controller an implicit integral action. Simultaneous state and disturbance estimation can be performed using an augmented statespace model [43], although a solid theory concerning nonlinear observer is not available. The basic structure of the NMPC is shown in Figure 1.6.

Figure 1-6: Basic structure of NMPC [4]

As Figure 1.6 shows, NMPC is a control-loop controller: it is a function of the current estimated state obtained by feedback, and it uses only the first sample in the optimal sequence (1.10), according to receding horizon principle.

29


1.4 NMPC as a Nonlinear Programming Problem As described in subsection 1.2.1, NMPC requires that a Nonlinear Programming problem (NLP) be solved on-line at each time step, in order to compute the optimal control sequence (1.10). For the NMPC, the optimization problem is highly expensive since it is generally nonconvex because the model equations are nonlinear. In the scientific literature one the most interesting challenges concerning NMPC is to develop an efficient and dependable method of solving the NLP; there are, in fact, many differences between Linear Programming problem (LP) and NLP, which result in significant differences between their solution methods [44]: for the NLP and in opposition to the LP, (i) optima are not restricted to extreme points, but could be along an edge of the feasible region, in the interior of the feasible region, or at an extreme point, (ii) there may be multiple disconnected feasible regions, (iii) there is no clear determination of the outcome since it is difficult to discern a local optimum from a global optimum. In NMPCs it is possible to use many different NLP solvers, which are potentially based on different algorithms: each of these may lead to a different solution. The length of prediction and control horizons even affects the time-performance of the NMPC [41]: the prediction horizon is chosen for control reasons as well as possible trade-off between the stability of closed-loop (long horizon) and the computational time required to solve the optimization problem (short horizon). The control horizon is often chosen equal to the prediction horizon, as already mentioned in Subsection 1.2.1.

But nevertheless, the main difficulty is that the NLP problem based on (1.5), (1.2a), and (1.3a), has a potentially large number of decision variables: regardless of the other issues, NLP solution can be too computationally expensive for on-line implementation on current calculator. Today there are various approaches to remedy this problem: for example, it is possible to perform Jacobian linearization about a nominal operating point and discretize the resulting linear model [43]: the consequent optimization problem can be solved with a Quadratic Programming solver; a recent development of this strategy is proposed 30


by Bequette [45], who suggests using, before each NMPC iteration, the current operating point to linearize the model. The NMPC computational efficiency can be also improved by solving the optimization problem and the model equations simultaneously [46], by reducing the number of decision variables [47], or using an alternative NMPC formulation, since some formulation allows better efficiency. Lastly, it is equally important to choose an NMPC solver according to the features of the plant [48].

Today, the interest in NMPC implementability is massive: in the scientific literature many papers describing the simulation and/or emulation of NMPCs can be found. The review conducted by M.A.Henson [43] gathers these scientific papers in order to identify a trend into the process of evaluating the performance of the NMPC. In fact, computer simulation and emulation are very powerful tools to evaluate the basic features of the NMPC: however, simulation and emulation are two distinct testing phases, since they differ in their purposes (for details see subsections 3.1.1 and 3.1.2). Table 1.3 lists a summary of some representative NMPC simulation studies: for each simulation study, Table 1.3 shows the process to be controlled, the model used to represent the process and its size (

), and the solution method employed.

Table 1.4 illustrates some representative NMPC emulation studies instead: it can be seen from the table that the number of papers is surprisingly low, especially compared to the number of papers in Table 1.3. This underlines that today many NMPC studies do not reach the emulation test, which is useful in evaluating the controller behavior on real-time hardware.

31


Table 1-3: Representative NMPC simulation studies [43]

Table 1-4: Representative NMPC emulation studies [43]

32


Chapter 2: Model Predictive Control in the Automotive Industry In recent years, the technological innovations, such as new efficient MPC algorithms, the increased computational power of the Electronic Control Units (ECU) and, simultaneously, the need to manage increasingly complicated problems concerning vehicle driving, have encouraged the application of the MPC in the automotive industry. In fact, many scientific studies confirm a great deal of interest in using the MPC on vehicle systems: this control strategy can be used to reduce fuel emissions [49], overcome engine problems [50],[51], improve vehicle active safety [52],[53],[54],[55], manage autonomous vehicle systems [56],[57], supervise mechatronic actuators, etc. ; MPC can be also employed in the emerging sector of Electric Vehicles. Unfortunately, typical process control problems in the automotive field are subject to stricter constraints, such as shorter sampling periods and reduced computational and memory resources, which make it difficult for the successful implementation of the MPC; the inherent non-linearity of the process to be controlled further complicates the situation.

In this chapter, the author illustrates the characteristics of the MPC used in the Automotive industry, highlighting the differences with the MPC used in its ordinary context; he also describes its potential benefits and the open challenges in Section 2.1, and he summarises the MPC applications in the automotive area in Section 2.2.

33


2.1 Characteristics of the MPC used in the Automotive Area Typical process control problems in chemical and petrochemical industries, which represent the industry sectors where the MPC is most frequently used, are usually characterized by relatively long sampling periods; additionally, in these industrial sectors, it is possible to employ calculators with extremely high computational power and memory resources to manage the control problems. On the other hand, in the automotive area, the situation is quite the opposite: the sampling periods are generally measured in milliseconds and the computational power and the memory resources of the ECUs are limited for mobility and cost reasons; furthermore, in this field, several applications have inherent nonlinearities. In line with Section 1.3, all these factors considerably complicate the implementation of the MPC on a real hardware: might be impossible to satisfy the hard real-time constraints determined by short sampling periods. However, various methods can be used to speed-up the MPC on-line computations, in order to allow the MPC solver to find a feasible solution within the used sampling period: for example, it is possible to use a hardware architecture for parallel computations [52], or wisely combine multiparametric programming and suitable process design [58]. Lastly, the employment of faster but less accurate optimization algorithms can help resolve the above-mentioned sampling period problem, but it degrades the performance of the MPC.

Therefore, in the automotive industry it is vitally important to confirm through emulations the implementabilty of the MPC on a real ECU, by evaluating the computational load for each MPC iteration, the amount of time required for each iteration, and the memory consumption. Nevertheless, most of the projects concerning the automotive MPC are limited to simulation studies, that are used to assess the behavior and the performance of the controller, independently of the hardware used. In fact, only an emulation leads to reliable data about execution times and memory consumption, since it is based on a real-time and it uses the information concerning the hardware characteristics of the system on which the controller will be implemented (for details see Chapter 3). 34


2.2 MPC Applications in the Automotive Area Today, the interest in the automotive industry for the MPC is really strong and several companies, including Toyota, Ford, BMW and Honda, endlessly contribute to the research. In this section, the author briefly illustrates some of the most important MPC applications in the automotive field, remarking the very small number of realised emulations in relation to the number of simulations. It is also important to stress the even smaller number of NMPC emulations: in all the considered cases, the emulation show the impossibility of implementing the controller on real hardware, because of its extremely high computational complexity; it is therefore necessary to find alternative implementations of the NMPC. 2.2.1 Fuel Economy, Emissions, Thermal Management The automotive control should ensure compliance with many different requirements, such as ride comfort, energy management, environmentally compatible fuel economy, for instance; in this context MPC has a great opportunity to meet the challenges, thanks to its ability to solve constrained optimization problems in which potential multiple objectives usually conflict with each other. Today, the constraints determined by the above requirements are even stricter, due to the introduction of new norms and standards; for example, car manufacturers are constrained to produce vehicles with high fuel efficiency and low emission, due to legal norms and increased cost of fuel. The vehicle energy consumption depends on various factors: vehicle engine, powertrain system, driving behavior, and others. One of the several model predictive control strategies employed to minimize fuel consumption is presented by B.Saerens et al. [59]: the paper illustrates the capabilities of the MPC for increasing gasoline engine efficiency. Instead, the control system realised by A.S.Kamal et al. [60] measures the relevant information of the current road and traffic, and it uses an MPC to predict the future state of the vehicle and compute the optimal vehicle input, in order to maximize fuel economy; the performance of the vehicle controlled by MPC is also compared with typical Gibbs vehicle performance: these results are shown in Figure 2.1 and Table 2.1. 35


However, in both cases only simulations are performed.

Figure 2-7: Fuel consumption in 100 randomly chosen independent cases [60]

Table 2-5: Comparison of MPC and GIPPS vehicles [60]

Idle Speed Control (ISC) is one of the major aspects of engine operations since vehicles usually spend too much time and fuel at idle: the main aim of ISC is to reduce as much as possible the engine speed while preventing engine stalls and therefore improving fuel economy. In [61], S.Di Cairano et al. develop an Explicit MPC (which can be used only on systems with reduced order) for regulating the engine speed to the idle speed set-point, and in [62] an LMPC is developed to solve Deceleration Control problem, which is similar to ISC. In [61] and [62], both simulations and HIL simulations are employed. Also the problem regarding nitric oxides (

) emissions can be solved by using the MPC:

in [49], T.L. McKinley and A.G.Alleyen introduce an Adaptative MPC based on a nonlinear, reduced order model; the MPC is demonstrated only in Simulation. 36


Pure electric vehicles are not subject to fuel economy and emissions constraints but they have limited capabilities, principally due to their really short maximum range per charge; Hybrid Electric Vehicles (HEV) are a halfway choice in terms of fuel consumption, emissions, and driving performance. However, HEVs require more complex control strategies [63], [64], since they use two or more distinct power sources: they usually combine an internal combustion engine and an electric motor. For example, in [64], H.Borhan et al. develop a Linear Time-varying MPC and an NMPC control strategy for solving the fuel minimization problem of the power-split HEV, which combines the advantages of both series and parallel HEV (power-split HEV structure is shown in Figure 2.2). In the nonlinear case, the short horizon allows the NMPC to solve on-line the optimization problem, showing a considerable improvement in fuel economy with respect to the current commercial solutions: unfortunately these analyses are conducted only in simulation.

Figure 2-8: Power-split HEV configuration [64]

In HEVs many components achieve the functionality of heating up the cabin temperature: in [65] H.Esen et al. propose an MPC to solve the cabin heat thermal management problem: once again, only simulation results prove the suitability of the proposed approach. 37


2.2.2 Active Safety In the automotive industry, there is today a keen interest in the active safety that complements the passive safety counterpart: active safety is primarily focused on vehicle driveability and stability in potentially dangerous situations, whereas passive safety is primarily focused on the structural and functional integrity of the vehicle. Antilock Braking System (ABS) and Traction Control System (TC) represent the first works on active safety: these systems date back to the 80s, and they are focused on improving vehicle longitudinal dynamics; obviously, the interest in active safety rises later, thanks

to latest innovative control strategies, like the MPC, which allow solving

even more complicated control problems.

Active Front Steering (AFS) is a vehicle steering system in which the relationship between the steering angle, imposed by the driver, and the road wheels angle may be altered according to vehicle speed, in order to improve lateral vehicle stability. In [57] and [66], P.Falcone et al. introduce two different MPC formulations to solve the AFS problem; the first MPC uses a nonlinear model of the vehicle, and an emulation on dSPACE show that the computational complexity of the NMPC is an obstacle for its implementability on a real hardware: limited to the computational complexity of NPSOL, which is the solver employed to solve the NLP, and the hardware used, it is possible to control the vehicle at low speed only. The second MPC formulation, which is based on successive linearization of the nonlinear model, is able to overcome this problem, with a substantial reduction of the computational burden. The results of [57] underline the need to use a high-performing hardware and/or an appropriate solver, in order to allow the implementability of the NMPC; otherwise, it is necessary to realise an alternative formulation of the controller. Table 2.2 shows the maximum computational time required by NMPC (Controller A) and suboptimal MPC (Controller B):

and

denote

the prediction horizon and the control horizon, respectively.

38


Table 2-6: Max. computation time of NMPC (Controller A) and SuboptimalMPC (Controller B) [57]

Electronic Stability Control (ESC) is a vehicle system that improves the stability of the vehicle by detecting and reducing loss of traction through differential braking. In [53], D.Bernardini, S.Di Cairano, A.Bemporad, and H.E.Tseng, propose a Hybrid MPC strategy to control vehicle steering by actuating AFS and ESC; in [66], [67], in order reduce the computational complexity of the previous controller, they propose a Switched MPC to solve the same problem: an emulation on dSPACE confirms the real-time implementabilty of this MPC in a real ECU. 2.2.3 Autonomous Vehicle The Autonomous driving of every vehicle, without the intervention of a human driver in a real traffic situation, requires the handling of many different scenarios, such as parking and obstacle avoidance, in order to improve passengers comfort and safeguard road safety: therefore, accurate models of driver behavior play a critical role in these applications [68]. Clearly, also the MPC can be helpful in this context; in fact, in the autonomous vehicle area, a model predictive based control strategy efficiently replaces the driver [52]: the MPC can predict the future state of the vehicle, according to its actual state, limitations, road and traffic information, and plan the future vehicle trajectory by comparing the predicted state with the desired one. Then, the MPC outputs the steering, accelerating, or braking; the entire procedure is repeated when the vehicle reaches a new state. The structure of the MPC which simulates the driver’s behavior is shown in Figure 2.9 (the same MPC structure is also used in some active safety applications). Examples of MPC used on Autonomous vehicles are presented in [56], [57].

39


Figure 2-9: Human driver model based MPC [52]

40


Chapter 3: Basic Characteristics of dSPACE Emulation A system project usually involves several phases, from preliminary analyses, which consist of many different investigations (such as requirement analysis, domain analysis, and cost analysis) to deployment, which also includes further activities (for example the maintenance operations of the system). Therefore, the technical decisions that are made in the controller life-cycle critically impact both the system characteristics and development process effort. In order to allow a considerable time, effort, and costs saving, the Rapid Prototyping Process (RPP) can be employed: this development approach cleverly coordinates the various testing activities, which heavily affect the development of any system. It is possible to employ, in fact, various testing activities, such as Simulations, Emulations, and Prototype testings, depending on testing purposes, development process phase and other factors.

In this chapter, the author illustrates the characteristics of the control system testing activity: he explains the meaning of Simulation and Emulation as Rapid Prototyping Process phases in Section 3.1, and he describes dSPACE SIL and HIL testings, their role in the automotive industry, and all the necessary HW and SW components to employ them in Section 3.2. Finally, the author shows the testing activities which may be employed on an NMPC using Rapid Prototyping Process and dSPACE in Section 3.3.

41


3.1 Testing In order to explain the meaning of the term Testing, it is possible to use the definition included in IEEE Std. 610.12.1990, the standard glossary of SW Engineering terminology:

“ The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.”.

Therefore, the above term is employed in Software Engineering to address several activities, which are used to find software errors and other defects into the system and verify that the software product is fit for use; outside the context of the Software Engineering, testing more generally denotes a performance evaluation analysis, which is used to assess compliance of the implemented system behavior with the expected one. Contrary to common belief, performance evaluation is an extremely complicated operation that cannot be produced mechanically, since every evaluation requires an in-depth knowledge of the system; in fact, in any performance evaluation analysis, we usually select a particular methodology, workload, performance metrics, and tools, depending on system characteristics, analysis goals, and other factors.

Selecting an evaluation technique and selecting performance metrics are the most important steps in the entire performance evaluation project. There are, in fact, three performance evaluation techniques (analytical modeling, simulation, and measurement) and several performance metrics [69]: the choice of the performance evaluation technique to use is affected by 7 factors, which are ordered from most to least important in Table 2.7; on the other hand, performance metric selection is largely influenced by system characteristics and analysis goals.

42


Table 2-7: Criteria for selecting an Evaluation Technique [69]

In accordance with Table 2.7, the analytical modeling takes a short time, it is the cheapest alternative, and it does not require a real implementation of the system; it also allows to make assumptions and simplifications on the considered system. Therefore, this evaluation technique is frequently used if you want to analyse a system in the early phases of the development process, evaluate a really complex system, or estimate an upper bound on the system performance. Simulation is an intermediate approach between analytical modeling and measurement: it leads to an arbitrary level of detail in results, and it is not too expensive. For these reasons, simulation usually takes a long time since it is often used to test as many situations as possible on the system; clearly, a higher level of details corresponds with higher cost and effort. Measurements are the most expensive alternatives since they require real equipment and instruments, and they usually take very long time; it is also important to underline that some performance parameters can be estimated only through a measurement. Therefore, measurement is frequently used if you want to analyse a system in the late phases of the development process, or estimate a particular set of parameters, which is impossible to evaluate using other evaluation techniques.

Considering the aims of the thesis, the author does not refer to analytical modeling and he focuses on the Simulation, Prototype testing, as a measurement-based evaluation technique, and Emulation, as an intermediate approach between the previous ones. 43


3.1.1 Simulation Simulating a system (or a process) means reproducing its behavior over time: first of all, it is necessary to create an appropriate model which describes the essential characteristics of the evaluated physical system, or abstract system, and use it to predict the system behavior through a computer. Therefore, the model represents the system and the simulation represents how the system works over time. On the basis of the above, if the real system is not available, simulation becomes an essential tool to evaluate the system performance; moreover, even if the real system is totally available, a simulation may be preferred over a measurement, since it allows to test the system under various circumstances and workloads, which might not be used in a real test environment. However, a simulation cannot perfectly reflect the system behavior over time, even if the simulation model exactly matches the referred system, since a simulation model maintains its own simulation clock, which certainly does not measure the real time. In fact, simulation time is an internal variable of the simulator: simulation time does not change continuously, but the simulator adds a quantity to its current value when an event happens. Therefore, the events are asynchronous, the simulator, that produces the events and schedules them in a proper way, is an event-driven system, and the clock signal is just an index that establishes the position of the event-occurrences in the event-sequence. Obviously, the execution of an event, that usually produces new ones, corresponds to the execution of a subroutine, which determines a state-transition in the simulated system: the simulation time is then increased depending on event characteristics.

Considering the purposes of the thesis, the above description is fundamental since it explains why some performance parameters, and in particular those parameters related to time, cannot be evaluated through a simulation: this evaluation technique is based on a virtual time that is not synchronized with a real-time clock and cannot be used to work on a real-time HW.

44


3.1.2 Emulation Emulation can be considered as a halfway approach between Simulation and Prototype testing; in fact, Emulation is practically a real-time simulation: this would also make possible to replace functional parts of the simulation model with parts of the real system. As already mentioned in Subsection 3.1.1, all models are an approximation of real systems: an emulation model tries to minimize the gap between the simulation model and the real system, by replacing part of the simulation model whit real system components, or placing the simulation model in a realistic environment. Therefore, emulation can also be considered as a measurement-based approach, since it allows to evaluate some performance parameters that are typical of the real system. Consequently, there are many differences between simulation and emulation [70]; first of all, they differ in their aims: simulation is frequently used to demonstrate the functionality, performance level, and operating limits of the analysed system in a cost-effective and flexible environment, which is based on a virtual time; on the other hand, emulation is often used to verify the results obtained in simulation, and estimate performance parameters related to time: in fact, emulation is based on a (discrete) real-time, since it must reflect reality. So, unlike a simulation, which can provide a response faster than real time, an emulation performs operations and produces outputs with the same time period as its physical counterpart would, considering the hardware characteristics of the employed system. Simulation and emulation also differ in terms of repeatability; this attribute is essential for simulation since it is necessary to recreate and understand events during the runs: all of the simulations must produce precisely the same results if no parameters are changed between the runs. However, the lack of repeatability in emulation, due to non-determinism of the real system components, is not a problem but a chance: the emulation can be also used, for example, to prove the robustness of a control system. Obviously, an emulation is useful and economically justifiable when: (i) the available time does not permit a real environment testing before the deployment of the system, (ii) the system is not available in real environment, (iii) real testing is expensive or dangerous. 45


3.1.3 Prototype Testing Employing a Prototype testing means evaluating system behavior and performance in a real or realistic environment through a prototype, that is an early implementation of the system intentionally built to test purposes. Prototypes are largely used in engineering since they allow to analyse and modify systems before implementing them in a large scale. Clearly, a prototype is not meant to be a perfect version of the final system: in general, a prototype may be built from different materials and using different fabrication process than the final system; it can be also a simplified version of the final system, since some structural and functional parts of the final product might be not necessary for the analysis. Consequently, engineers and other specialists attempt to minimize the impact of these differences on the analysis results. Prototype testing is nevertheless afflicted by several limitations: (i) prototype testing is used to reduce the risk that a system may not perform as intended, but this risk cannot be completely eliminated, (ii) a prototype is usually much more expensive than the final system, due to inefficiencies in materials and processes, (iii) tests can be difficult to reproduce. For these reasons, an emulation is generally preferred; nevertheless, prototype testing can be employed after the emulation, in order to evaluate the system in a completely real test environment.

For example in the automotive control system field, after simulations and emulations, we can think of implementing the control algorithm on an FPGA, which represents the HW prototype of the control system, in order to test the control action on a cheaper and safer vehicle, which represents the prototype of the car instead. In fact, using the ECU of the real vehicle, any test failure translates into economic losses and hazardous situations. Therefore, in order to avoid any economic and safety risk in the automotive testing, Hardware-in-the-Loop (HIL) simulation tends to be used, which is a particular type of Emulation and represents a smart alternative to prototype testing, (for details see Subsection 3.2).

46


3.1.4 Rapid Prototyping Process Emulation is not an usual operation in the traditional development process, which normally employs only simulation and prototype testing (or real system testing). In fact, the employment of the emulation has been made possible in recent years by automatic code generation systems, which automatically encode the simulation model in an executable file for the real-time target hardware. These systems that automate the encoding process, compilation process, linking process and download of the obtained executable, allow to effortlessly analyse the system in a realistic environment without creating a prototype: if the results obtained through the emulation are acceptable, it is possible to produce the system, otherwise it is necessary to come back to the previous phases of the development process and modify the system; if you use an automatic code generation system, these iterations do not cost anything. The development process based on the above-mentioned systems is named Rapid Prototyping Process (RPP) [71].

Figure 3-10: Comparison of Traditional and Rapid Prototyping Development Process [71]

47


In control engineering, if you develop a control system with a traditional approach, many engineer teams have to work for its implementation: an Algorithm Design team specifies the algorithmic characteristics of the control system, and these characteristics will be implemented and tested in a simulated environment by a Software Design team; simultaneously, a Hardware Design team specifies the features of the Hardware system on which the controller will be implemented: these features could be modified by an Implementation team, which adapts the supposed features to the real system. Undoubtedly, this approach is extremely expensive since each phase is really far from the others. For example, the Algorithm Design team that implements the control algorithm does not consider the hardware characteristics of the target system; so, when an implementation problem happens, an iteration towards a previous phase would be costly, in terms of both time-wasting and expense.

RPP mixes the four previous phases removing potential bottlenecks; the first phase of this process starts in a simulation environment, such as Matlab/Simulink, in which it is possible to develop the system model and simulate it in order to evaluate its properties: if results are not satisfying, it is possible to iterate modeling and analysis phases until they are adequate. When the desired results are reached, it is possible to develop a real-time implementation of the control system, in order to evaluate its characteristics on a real-time hardware (Emulation): as already mentioned, this process is simplified by automatic code generation systems, such as dSPACE RTI and Real-Time Workshop; potential iterations towards the previous phases are therefore cheaper. A possible control-system RPP (if you use Matlab/Simulink and dSPACE) is shown in Figure 3.11.

48


Figure 3-11: The Rapid Prototyping Development Process using Matlab/Simulink and dSPACE

In some field, like the automotive one, (pure) Emulation is named Software-in-the-Loop (SIL) simulation, since it allows to recreate the real-time behavior of a system through a simulation software, without physically connecting the real hardware. After emulating the system, instead of building a prototype, parts of the real-time simulation model can be progressively replaced with real system components: this particular type of Emulation is called Hardware-in-the-Loop simulation (HIL) instead. Obviously, both SIL and HIL can be considered as special types of Emulation; however, these performance evaluation techniques are not mutually exclusive: they are both used in the automotive development process in accordance with the V-model traditionally used for development and test. 49


3.2 dSPACE SIL and HIL in the Automotive Industry As already mentioned at the end of Subsection 3.1.4, HIL is a performance evaluation technique in which one or more real components interact with the simulation model of the system, that is real-time simulated (let us remember that a real-time simulation is an emulation). The analysis management and the real-time interaction between the real part and the emulated part of the system have been made possible by some hardware and software components which together constitute the HIL System. The structure of the HIL System can considerably vary from application to application, but despite this, it is possible to identify some standard components: a Real-Time Processor, a Host PC, a load simulator, I/O boards, signal conditioning components, bus systems, and failure simulation units. Clearly, the Real-Time Processor, that is equipped with a dedicated realtime operating system designed for maximum I/O throughput and minimum I/O latency, is used to emulate the system model; instead, the Host PC is used as an interface to the real-time processor system and for executing the analyses. Clearly, HIL System can also be used to employ a SIL simulation (also referred as pure Emulation).

Figure 3-12: dSPACE HIL System [72] 50


Nowadays, model-based development, automatic production code generation, SIL simulation and HIL simulation are integral parts of the automotive development process: dSPACE supports all the above development phases with its products. Today, dSPACE Systems are used for developing and testing embedded electronics in many different application fields, such as engine control, powertrain control, vehicle dynamics, autonomous driving, and driver assistance systems. For example, SIL simulation and HIL simulation are the best methods for meticulously testing the ECU functions: through the SIL simulation it is possible to execute both the ECU functions and the vehicle model on the real-time processor; through the HIL simulation, instead, it is possible to run a test in which the real ECU interacts with the emulated vehicle model. So, SIL and HIL tests are easy to reproduce, they can run automatically, and they are completely safe, even while testing critical situations (Safety-Standard ISO 26262, in fact, recommends HIL testing as a suitable method for testing safety-related functions, components, ECUs, and ECUs networks) [73].

Figure 3-13: ECU functions testing through dSPACE HIL Simulation [72]

51


Obviously, to use the dSPACE HIL System efficiently, it is necessary to create a realistic model of the system under test, and this can be done using MATLAB, Simulink, or Stateflow. dSPACE simulator systems, in fact, are open for use with third-party and custom models. On the other hand, dSPACE analysis clearly requires the use of vendor proprietary software, such as dSPACE ControlDesk and dSPACE Profiler. 3.2.1 dSPACE Real-Time Interface dSPACE Real-Time Interface (RTI) is used to automatically encode the Simulink model in an executable file for the dSPACE board: dSPACE RTI is thus the automatic code generation system that allows employing the RPP in dSPACE simulator systems. So, RTI, that extends the C code generator Coder, is the link between simulation models and realtime dSPACE hardware [74]. To connect the Simulink model to a dSPACE board you just have to drag and drop the appropriate modules from the RTI block library in the Simulink file, and with a quick click on Build, the real-time model is automatically generated, compiled and downloaded. Therefore, it is possible to save time and effort, since it is not necessary to manually convert the Simulink model into another language, and worry about I/O function calls, or about hardware characteristics of the target board. Obviously,

in order to build the project and create the executable file for the target board, RTI uses a cross-compiler. The required software and hardware to use dSPACE RTI are listed in Table 3.8.

Table 3-8: Required Software and Hardware to use dSPACE RTI [74] 52


3.2.2 dSPACE Kernel and Scheduler Any real-time system is usually composed of several tasks: for these systems multiprogramming is fundamental since it allows to carry out multiple tasks at the same time by executing them concurrently through the use of common resources. After all, it is important to point out that multitasking does not imply parallel execution since these tasks are not executed simultaneously. This is only possible in a multiprocessor system.

Obviously, one of the main objectives of the Kernel, that is the core of the operating system, is to define a suitable tasks scheduling order by using an appropriate scheduling algorithm: in an ordinary operating system, Kernel usually defines the scheduling order trying to maximize the CPU-use and/or minimize the response time of the processes, whereas, in a real-time operating system, Kernel defines the scheduling order trying to satisfy tasks’deadlines, since each task must complete within its characteristic time interval. In addition, by using the same scheduling algorithm, Kernel manages the state of the tasks by starting, blocking, and resuming them. One of the simplest states-model is shown in Figure 3. 14, although it is also possible to consider more complicated models relating to specific operating systems: the task is (i) Blocked when it cannot be executed by CPU waiting for a specific event, (ii) Ready when it is waiting to be executed by CPU that in the meantime carries out another task, (iii) Running when it is executed by CPU.

Figure 3-14: Task - 3-state Model 53


Preempt is one of the most important state-transition since a Running task might become Ready for a number of reasons: if you use a priority-based scheduling algorithm, the current task is preempted when a task with higher priority becomes Ready; on the other hand, if you use a timeline scheduling policy, the current task is preempted when its time slice ends. When the CPU preempts a task, there is a swap between the task currently executed and one of the tasks placed in the ready-queue: the entire swap routine is named context switch and it increases the system overhead. Clearly, only one of the ready tasks will be executed by CPU when the currently running task terminates: this choice is made by Scheduler, which is one of the components of Kernel, by using a scheduling algorithm selected on the basis of system purposes and task features.

dSPACE RTI uses dSPACE Real-Time Kernel (RTK) to handle interrupt signals and efficiently manage and schedule the tasks of the obtained real-time model. In fact, the real-time code is not executed as whole, but dSPACE RTI subdivides the real-time model according to the structure of the Simulink model and assigns the parts to the tasks. Task activation request is done with interrupt signals, which are generally originated from a CPU timer-device (internal event) or an I/O device (external event). dSPACE RTI uses dSPACE RTK to handle interrupts and dSPACE scheduler to efficiently schedule the tasks. dSPACE scheduler assigns a numeric value to tasks in order to identify their state, according to Table 3.9, and it executes the tasks using the following rules [75]:



A high-priority ready-task always suspends a running-task with lower priority.



Two tasks with same priority cannot suspend themselves: they are managed with First-Come-First-Served policy (FCFS).



If no task with high priority is currently triggered, the earlier suspended task can resume its execution.



If all tasks have idle-state, dSPACE scheduler executes Background task, which has no priority and it is usually composed of uncritical time-operations.

54


Table 3-9: dSPACE task 3-states model [75]

Figure 3-15: Example of dSPACE scheduling [75]

dSPACE scheduler is a priority-based preemptive scheduler that supports priority-based Rate-Monotonic (RM) scheduling algorithm, which is characterized by the following properties:



On-line: scheduling order is chosen run-time through a set of preexisting rules.



Static: priorities cannot be changed run-time.



Preemptive: currently executed task can be blocked at any time in order to assign the CPU to a higher-priority task.



Task priority is directly proportional to task activation frequency: RM assigns a high priority to task with short period and vice versa (user can always manually change task priorities). 55


Based on the above, higher-priority tasks interrupt lower-priority tasks, and the consequent interrupt handling inevitably causes a time overhead, which is named switching-time: there is, in fact, a delay between the interrupt request and the execution of the corresponding task on the Hardware. A triggered task with the highest priority has the task-switching times listed in Table 3.10 if the involved routine is already located in the cache; otherwise, the time overhead might be significantly longer.

Table 3-10: dSPACE RTK Task-switching time [75]

56


3.2.3 dSPACE Tasks Execution Modes Any Simulink model is composed of periodic and aperiodic components: the periodic components are regularly activated at constant frequency, whereas the aperiodic components are characterised by their specific start time and computation time; consequently, a real-time model obtained from a Simulink model could be composed of parts with different sample times. dSPACE RTI provides two different execution modes to handle the different sample times of the real-time model [75]:



Single timer task mode, that combines all sample times in one single Timer task: in this case, there is only one task and no preemption.



Multiple timer task mode, that creates an individual Timer task for each sample time: in this case, there are many tasks with different priority, and preemption is possible.

Based on the above, when dSPACE RTI uses single timer task mode, that is used by default, it collects all the blocks in one Timer Task: this task will be executed whit the fastest sample time of the model, that is the base sample time. However, in emulation, single timer task mode could lead to unexpected overrun situations, since the overrun is referred to the entire Timer Task and not to its component blocks (see Figure 3.17).

Figure 3-16: Example of single timer task mode scheduling [75]

Figure 3-17: Overrun situation using single timer task mode [75]

57


3.2.4 dSPACE ControlDesk and Profiler dSPACE ControlDesk (CD) is the software provided by dSPACE for accessing the simulation platform and creating, managing, and analysing the experiments on dSPACE simulator systems; clearly, dSPACE CD efficiently supports SIL simulations, HIL simulations, offline simulations and diagnostic. Moreover, dSPACE CD provides several helpful tools for measuring data experiment: these data can be immediately displayed onto screen by using plotters and other graphic tools, or they can be saved to a file for subsequent processing.

Despite the huge potential of dSPACE CD, in some cases it is necessary to employ additional software and tools, in order to extrapolate the desired data. In fact, dSPACE CD allows to measure time-related parameters, but it does not allow to evaluate the duration of user-defined events: for instance, it is not possible to measure the execution-time of a particular subsystem of the real-time model. The measuring of the user-defined events has been made possible by dSPACE Profiler. However, dSPACE Profiler adds additional instructions to the real-time application instruction-flow: this introduces additional overhead, which depends on number of profiled events (this overhead is added to the turnaround time both for the registration and the execution of the task). Table 3.11 lists the approximate worst-case execution time overhead introduced by dSPACE Profiler (the first value of Overhead not filtered column is the measured overhead for the multitimer task mode, the second value is the measured overhead for the single timer task mode).

Table 3-11: dSPACE Profiler Overhead [76] 58


3.3 NMPC Testing Activity On the basis of the information reported in Section 3.1, organizing a testing activity for an NMPC is an extremely difficult operation, since the analysis might be divided into multiple steps with different purposes, each of which must be used in a specific phase of the controller life-cycle. Let’s suppose to use the RPP as a controller development process, Matlab/Simulink as a simulation environment, and dSPACE for the emulation:

1. Following the NMPC design, multiple Matlab/Simulink simulations can be used to assess NMPC behavior and performance: in the worst case, control performance is unacceptable and the control engineer is forced to review the previous phases of the development process and modify the NMPC in order to improve its performance.

2. When the simulation results are adequate, it is possible to employ dSPACE RTI to automatically encode the Simulink model in an executable file for the dSPACE board: dSPACE SIL simulation can be used to confirm the results obtained in simulation on a dedicated HW without connecting the real ECU. For the NMPC, the emulation has another important objective: determining if the NMPC can be employed in a real-time environment. In fact, it is necessary to assess whether the resulting NLP problem can be solved within the desired sampling period, and this analysis cannot be performed through a simulation, as described in Subsection 3.1.2. Using dSPACE Profiler, it is possible to measure the time required by solver per call to solve the NLP problem, and verify whether it is smaller than the given NMPC sampling time. Even in that case, if the performance of the NMPC is unacceptable, the control engineer is forced to review again the previous phases of the development process.

3. When the SIL Simulation results are adequate, it is possible to employ a dSPACE HIL simulation and eventually a prototype testing.

59


Chapter 4: Case Study – Automotive-NMPC Design and Simulation The key objective of the current project is to prove the real-time implementabilty of the NMPC in all the areas where the plant to be controlled is characterised by fast dynamics: in these application contexts, in fact, the NMPC implementability is made difficult by imposed hard real-time constraints. Therefore, in order to achieve this objective, we consider the automotive NMPC strategy [5] developed at Cranfield University’s Mechatronic Laboratory of the Advanced Vehicle Engineering Centre as case study. This control strategy, that has already been tested through simulations, can be used for the stabilisation of a vehicle near the limit of lateral acceleration using the real axle electric torque vectoring configuration of an EV. A four-wheel nonlinear vehicle model coupled with a nonlinear tyre model is used to develop three different MPC strategies of different complexity: a linear MPC strategy, an NMPC strategy that uses Real-Time Iteration scheme, and an NMPC strategy that uses the Primal-Dual Interior Point (PDIP) method. Simulation studies underline that the NMPC-PDIP is the most promising strategy, although it is characterised by long computational time; on the other hand, maximum computational time can be reduced by softening the yaw rate constraints. Thus, softconstrained NMPC-PDIP is then analysed through dSPACE SIL simulation.

In this chapter, the author presents the NMPC vehicle model and the MPC strategies in Section 4.1, and he summarizes the simulation studies employed on the MPCs in Section 4.2.

60


4.1 NMPC Design As already mentioned, the referenced control scheme can be used for stabilisation of an electric vehicle at the limits of handling. This Model Predictive Control strategy, that is presented in [5], extends some previous works [77],[78],[79] where the interested reader is referred to for details.

In the current Section, the author presents the vehicle model used in the MPC in Subsection 4.1.1, a short description of the steady-state analysis used to generate feasible target for the controller in Subsection 4.1.2, and the employed MPC strategies in Subsection 4.1.3.

4.1.1 Vehicle Model The Equations of Motion (EOM) of a four-wheel vehicle with front-wheel steering (Fig. 4.17) are given as follow:

Figure 4-18: Full-vehicle model [5] 61


̇

(

)

( ̇

)

)

(

) )

) )

)

(4.11a)

(

) -

̇

)

( )-

)

( ( )

(

( )

(

)

) (

( )

(

)

(

,( (

(

(

),(

(

̈

(

( )

( )

(

) (4.11b)

)

)

(4.11c)

̇

(4.11d)

In the above equations, of mass (CM),

is the mass of the vehicle,

is the vehicle velocity at the center

is the moment of inertia of the vehicle about the vertical axis,

is the

sideslip angle at the CM, ̇ is the yaw rate. The moment of inertia of each wheel about its axis of rotation is denoted by

, the angular rate of each wheel is

of each wheel is . The steering angle of the front wheels is , while

, and the radius is the drive/brake

torque applied on each wheel; the longitudinal and lateral tyre forces are denoted by while

,

determine the CM location with respect to the center of each wheel.

The self-aligning moments at the tyres and the rolling resistances are neglected instead.

that represent the tyre forces, can be found using Pacejka’s Magic Formula (MF). More specifically, the tyre force coefficient

is found using the MF, where

is the resultant tyre slip:

(

)

(

) √

(

(

))

(4.12a) (4.12b)

62


It is then possible to calculate the longitudinal and lateral tyre force coefficient from (4.13): (

)

(4.13)

The longitudinal and lateral tyre force are given by Formulas (4.14a) and (4.14b), where

is calculated as the sum of the static load on wheel and the longitudinal/lateral

weight transfers under longitudinal/lateral acceleration.

(4.14a) (4.14b)

Table 4.12 lists the typical values for a small sports car.

Table 4-12: Vehicle and Tyre parameters for a small sports car [5]

63


4.1.2 Reference Generation On the basis of the information listed in Table 4.12, a steady-state cornering analysis of model (4.11) is used in order to derive feasible targets for the controller to follow: using a neutral steer linear bicycle model under steady-state cornering (4.15), it is possible to obtain the desired path radius

from the driver as a function of the steering input. (

)

(4.15)

Then, the desired path radius might not be feasible depending on the velocity of the vehicle. We consider, for instance, the situations shown in Figure 4.19:

Figure 4-19: Selection of target steady-state according to the imposed steering angle [5]

In all three cases, the desired path radius angle command is or velocity is

is around

, since the driver’s steering

: if the velocity of the vehicle is

,

, the requested path radius is feasible. On the other hand, if the vehicle the desired path radius is no longer feasible, since it is 64


smaller than the minimum path radius achievable

. In this case, the controller reduces

the velocity of the vehicle so that the desired path radius becomes feasible. Obviously, this velocity reduction should be minimal: in order to achieve this objective, the controller selects a steady-state velocity such that the desired path radius minimum path radius achievable

coincides with the

. See [77], [78] for detailed discussion.

4.1.3 MPC Strategies The nonlinear continuous-time system (4.16) is considered, where

and

represent the

state and the input of the system, respectively. ̇

(

)

(4.16)

The optimal control problem, which reference is made, is (17).

∑ [(

)

(

)

(

)

(

)]

(4.17a) (4.17b)

Subject to

( (

)

(4.17c)

)

The simulation time is

, where

(4.17d)

is the sampling time, (17b).

The above minimization problem is subject to the initial condition (17b), the discretised system dynamics (17c), and the state and input constraints (17d).

For the MPC strategies, the cost function to minimize is (18): the objective is to minimize the state and input error from a given reference.

∑ [(

)

(

)

(

)

(

)]

(4.18a) 65


(4.18b)

Subject to

(

)

(4.18c) (4.18d) (4.18e)

Where

is the prediction horizon; the nonlinear constraints (17d) are replaced by

box contraints (18d), (18e).

Three different MPC strategies of different complexity are developed [5]:



An LMPC strategy, in which the nonlinear continuous-time system (4.16) is linearized and discretised; the resulting QP problem is solved with the PDIP method as available in Forces Pro [6].



Two NMPC strategies, where the explicit Runge-Kutta 4th order method is used to derive the nonlinear discrete dynamics (4.18c) from the continuous dynamics (4.16); a sampling time of

is used.

o The first NMPC strategy employs the Real Time Iteration scheme as available in the ACADO Toolkit to solve the NLP problem: this scheme produces fast but suboptimal solution by performing only one Sequential Quadratic Programming (SQP) iteration per sampling time (see [80] for details). o The second NMPC strategy employs the PDIP method as available in Forces Pro to solve the NLP problem, where the maximum number of iteration that solver can perform is set to

. Solver also employs the Broyden-Fletcher-

Goldfarb-Shanno algorithm for computing the Hessian and the Lagrangian. 66


4.2 NMPC Simulation The MPC strategies already described in Subsection 4.1.3 are then compared through several simulation studies, in order to determine the most promising MPC alternative. In this Section, the author briefly illustrates the results obtained through the simulation tests by Siampis [5], where the interested reader is referred to for more details. Simulations have been done using Matlab/Simulink on a standard desktop machine (i7-2600k at 3.40GHz with 16GB of memory), and the optimal problem (4.17) is solved offline by employing the SQP algorithm as available in ACADO toolkit, in order to obtain a benchmark against which the three MPC strategies are compared. 4.2.1 Simulation Results We consider the following scenario: the electric vehicle is initially moving on a straight line and at time

a step steering input for the duration of 10 seconds is applied;

the chosen initial speed of the vehicle is greater than the corresponding

for that

steering input. The fast wheel dynamics (4.17d) are neglected, and additional constraints are imposed on the system, as is shown in greater details in [5]. Simulation tests consider nine different steering angles of the front wheels

(from

to

), and four

different initial velocities (ranging from

above the

for that steering

input), the sampling time is set to

to

, and the prediction horizon is set to

.

Table 4-13: Computational times and performance results from the MPCs [5]

67


Table 4.13 shows the results obtained in the simulation tests: the average computational times and the maximum computational times are shown in the first two columns of the Table, and the minimum and maximum closed-loop costs are shown in the last two columns. Closed-loop cost, that is calculated by using a specific formula, is expressed as a percentage difference from the optimal. According to Table 4.13, we can see that the computational times vary according to problem complexity: the LMPC is the fastest strategy, whereas the NMPC-PDIP is the slowest; moreover, the NMPC-PDIP maximum observed time is much higher than the other strategies. On the other hand, NMPC-PDIP approach performs closer to the optimal than both LMPC and NMPC-Real-Time-Iteration.

Figure 4-20: Velocity and Yaw rate histories for =8deg and V=Vmax+4m/s for the 3 strategies [5]

Figure 4-21: Longitudinal slips histories for =8deg and V=Vmax+4m/s for the 3 strategies [5] 68


Figures 4.20 and 4.21 show the velocity, yaw rate, and longitudinal slip time histories for a step steering input of

and initial velocity of

for this

steering input. As shown in Figure 4.20, the velocity time history for the LMPC and the NMPC-PDIP are both close to the optimal trajectory; instead, only the NMPC-PDIP yaw rate time history is close to the optimal trajectory, whereas the LMPC yaw rate history is a bit far from the reference history. The NMPC-PDIP yaw rate time history is characterized by only a small overshot, which is directly connected to the oscillations observed in the longitudinal slip time histories. For this test scenario, as can be seen, NMPC Real-TimeIteration shows the less promising results, since it becomes unstable due to high initial state error. As it follows from these results, the most promising strategy is NMPC-PDIP, although it is characterized by long computational times: for this reason, it is necessary to review the previous phases of the development process and modify the chosen strategy.

4.2.2 Soft-Constrained NMPC-PDIP In order to endow the PDIP solver with a faster convergence, and at the same time avoid infeasibility problems, it is possible to relax the yaw rate constraints, and soft constrain the state by introducing slack variables into the cost function:

∑ [(

)

(

)

(

)

(

)

]

(4.19a)

(4.19b)

Subject to

(

)

(4.19c) (4.19d) (4.19e) (4.19f)

Where

are the slack variables (with

),

are their weights. 69


Figure 4.22 shows the differences in maximum and average computational times obtained in further simulation tests, between NMPC-PDIP and soft-constrained NMPC-PDIP strategies: the maximum time has decreased to less than half in all cases, whereas the average times are substantially the same, despite the inclusion of slack variables increases the number of decision variables (this is the main issue for the on-line implementation of the NMPC, as already described in Subsection 1.4). Moreover, the maximum number of iterations is never reached by the PDIP solver under any test circumstance.

Figure 4-22: Computational times for hard-constrained and soft-constrained NMPC-PDIP [5]

Figure 4.23a shows negligible differences in the already considered test scenario between the Hard-constrained and the Soft-constrained velocity time histories; in addition, according to Figures 4.23 and 4.24, if you soft constrain the NMPC-PDIP strategy, you can obtain both a smoother longitudinal slip and remove the yaw rate overshot. Furthermore, no infeasibility problems have been observed in all the simulation cases.

70


Figure 4-23: Velocity and Yaw rate histories for =8deg and V=Vmax+4m/s . for the Hard and Soft constrained NMPCs [5]

Figure 4-24: Longitudinal slips histories for =8deg and V=Vmax+4m/s . for the Hard and Soft constrained NMPCs [5]

Therefore, the soft-constrained NMPC-PDIP simulation results are adequate: it is thus possible to employ dSPACE emulations (SIL simulations) in order to confirm the results obtained in simulation and verify whether the time required by solver per call to solve the NLP problem is smaller than the given NMPC sampling time in a real-time environment. 71


Chapter 5: Case Study – Automotive-NMPC Emulation Following the Simulation studies, it is possible to employ a SIL simulation to confirm the results obtained in the previous analyses and estimate performance parameters related to time which cannot be evaluated through a simulation. The emulation analyses can be realised using the simulation system made available by dSPACE. Therefore, it is necessary to choose the dSPACE real-time hardware to use and define the objectives of the real-time analysis. In addition, before running the SIL tests, some preliminary activities should be undertaken to simplify the use of dSPACE CD and allow a proper use of dSPACE profiler. Upon completion of the tests, if the results are adequate, it is then possible to employ a dSPACE HIL simulation or a prototype testing; otherwise, it is necessary to review the previous RPP phases. Both vehicle model and soft-constrained NMPC-PDIP [5] are emulated on ds1005 dSPACE Board, in order to confirm the results obtained in simulation and verify the real-time implementabity of the controller. Furthermore, some preliminary analyses, which are not described in the thesis for reasons of clarity, have stressed the need to cap the maximum number of iterations that the solver can perform before returning a (sub-) optimal solution to

, due to limited processing power of the HW used.

In this chapter, the author describes the employed dSPACE hardware in Section 5.1, and the emulation test plan in Section 5.2. He also explains all the preliminary activities required for employing a dSPACE emulation in Section 5.3, the procedure for collecting data in Section 5.4, and the obtained results in Section 5.5. Lastly, he explains why to use a Benchmark to assess the performance of the dSPACE board in Section 5.6. 72


5.1 dSPACE Hardware – DS1005 PPC Board

Figure 5-25: DS1005 PPC Board [81]

The emulation analyses are performed by using dSPACE DS1005 PPC Board, which is equipped with a PowerPC 750GX processor running at 1 GHz and characterized by 32 KB L1 data cache, and 32 KB instruction cache (PowerPC 750GX processor is described in more detail in Appendix A). In addition, DS1005 is equipped with 128 MB SDRAM global main memory for host data, 1 MB L2 cache running at processor clock, and 16 MB flash memory for both user-specific application and boot firmware. Although it is quite dated (the end of life of the DS1005 is planned for 31 December 2020), the above-described board is one of the best choices for the application under consideration, since DS1005 is normally employed for the emulation of systems with high sampling rates and a lot of I/O capacity [81]. Unfortunately, DS1005 is not a multiprocessor system: it does not allow true parallel execution of multiple processes, such as the vehicle model and the soft-constrained NMPC-PDID. Table A.17 set out in Appendix A lists the DS1005 Board technical details, Figure 5.26 shows the block diagram of its HW structure.

73


Figure 5-26: DS1005 Block Diagram [81]

As shown in Figure 5.26, DS1005 is directly connectable to all dSPACE I/O boards via PHS and PHS++ bus. Moreover, the processor board can be connected to other DS1005 boards via DS910 Gigalink Module to create a multiprocessor system: the board's synchronization is ensured since the interrupt signals can be dispatched to boards via HW with minimal latencies. The characteristics of the buses, interfaces, and other DS1005 board components are not considered since only a SIL simulation is carried out. The characteristics of the employed Host PC, which is a component of the dSPACE system, are not described, since they do not affect the results of the emulation.

74


5.2 Test Plan As mentioned in Section 3.3, dSPACE SIL Simulation is employed to prove the real-time implementability of the soft-constrained NMPC-PDIP by measuring the time required by solver per call to solve the NLP problem, and then checking that it is smaller than the given sampling time. Clearly, the emulation is also employed to confirm the results previously obtained in simulation on a real-time dedicated HW.

For the emulation analyses, we consider the test scenario already used in simulation and described in Subsection 4.2.1: we consider (from above the

to

), and

different steering angles of the front wheels

different initial velocities (from

for that sterring input), for a total of

to

emulation test cases. For each SIL

simulation test, we take into account the velocity, yaw rate, and longitudinal slip time histories to confirm the simulation results; the computational times required by the solver per call, for each test case, is instead used to assess the controller real-time implementability. As in simulation, the fast wheel dynamics (4.17d) are neglected. The emulation time is set to therefore, we obtain

, and the sampling time is set to

:

samples for each test. Some preliminary SIL simulation tests

have stressed the need to cap the maximum number of iterations that the solver can perform before returning a (sub-) optimal solution to

, due to limited processing power

of DS1005. However, since each iteration takes a fixed time, the solver iteration time can be calculated as the ratio between the controller computational time per call, that is measured by dSPACE Profiler, and the solver iterations number per call, that is measured by dSPACE CD instead. Both vehicle model and soft-constrained NMPC-PDID use sampling time

. Hence, dSPACE RTI employs single timer task mode

to execute the real-time model: there is only one Timer task and no preemption, as detailed in Subsection 3.2.3.

75


5.3 Preliminary Activities To employ the dSPACE SIL Simulation, the soft-constrained NMPC-PDIP must be first deployed on a target board. It is therefore necessary to edit the source code of the FORCES Pro PDIP solver by the addition of lines of code which allow selecting the dSPACE target platform to use. Moreover, source code modifications allow disabling some solver options that do not permit a proper deployment. Also the project makefile might be modified in order to specify the location of S-functions or additional source code to compile: in FORCES Pro PDIP solver developed by Siampis, for example, some CasADi source files are used (CasADi is a free and open source symbolic framework for automatic differentiation and optimal control [82]). See the guide available on FORCES Pro website [6] for more details about code deployment on dSPACE platforms.

Additionally, in order to efficiently employ a dSPACE SIL simulation, it is necessary to carry out some preliminary activities which mainly simplify the execution of the tests and the extrapolation of the results. On the other hand, some of these activities must be carried out to allow the employment of extra tools, such as dSPACE Profiler.

In the current Section, the author describes how to simplify the execution of the tests through dSPACE CD in Subsection 5.3.1, and how to measure the execution time of single subsystems, such as the NMPC-PDIP solver, with dSPACE Profiler in Subsection 5.3.2.

76


5.3.1 dSPACE ControlDesk Employment As already mentioned in Subsection 3.2.4, dSPACE CD is the proprietary SW for accessing the real-time simulation platform, creating experiments and managing tests. dSPACE CD organizes the analyses in projects, each of which might be composed of one or more experiments: the experiment level is for organizing and managing tests by using several useful instruments. In the experiment level, for example, the user can visualize the measured data on plotters, bars, and displays, simply by linking the instruments and the variables via drag&drop. The analysis to which we are referring to does not require the use of plotters and displays, since the main objective of the emulation is just to measure the execution time of the NMPC solver; only afterwards, the data obtained through dSPACE CD will be compared to the ones previously obtained in simulation. Nevertheless, in the experiment we carried out, a display is used to continuously show the current emulation time, as shown in Figure 5.28; anyway, also other instruments could be used in order to display, for example, the velocity, yaw rate, and longitudinal slip time histories of the (real-time) simulated vehicle, or the number of iterations performed by soft-constrained NMPC-PDIP solver.

Figure 5-27: Selecting a project and experiment in dSPACE ControlDesk [83] 77


Figure 5-28: dSPACE ControlDesk – Experiment Layout

With dSPACE CD it is also possible to use tunable parameters, which allow changing the input values of the experiment without re-building the simulation model. In fact, as described in Section 5.2, the used test plan is composed of 36 tests, each of which is characterised by a different steering angle and initial velocity: it would be very costly, in terms of both time-wasting and effort, to re-build the model 36 times. Therefore, to tackle this issue, it is possible to use tunable parameters, in order to set the experiment input values directly in dSPACE CD during the SIL simulation without re-building the real-time model. To use steering angle (

) and initial velocity (

) tunable

parameters, it is first of all necessary to configure inline parameters in Simulink configuration (as shown in Figures 5.29 and 5.30), build the model as usual, and then link the obtained parameters with Numeric Input instruments in dSPACE CD. In order to further simplify the analyses, you can also use automation scripts. 78


Figure 5-29: How to configure Tunable Parameters in ControlDesk – Step 1

Figure 5-30: How to configure Tunable Parameters in ControlDesk – Step 2

For dSPACE platforms, a signal which is visualised in a plotter is automatically added to the list of the signals to measure. On the contrary, the signals connected with any other instrument will be observed, but not measured: in order to measure all the signals that you want to later analyse, such as the velocity of the vehicle and solver iterations number, it is necessary to manually drag&drop these signals in the measurement signal list, or add them to list through the Measurement Configuration. 79


As can be seen in Figure 5.28, a Radio button is connected to simState variable, that controls the simulation state and determines if the simulation is running, paused, or stopped (according to Table 5.14).

Table 5-14: Values of simState Variable [84]

It is essential to handle simState variable because, otherwise, some signals would not be measured in the correct way. In fact, simState variable is initialized with RUN by default: consequently, when the test is launched, the simulation starts instantly after the download, making it impossible to properly capture the behavior of the model at simulation start. We also must stress that the start-time of real-time simulation, which can be configured like the simulation stop-time from the Simulink Configuration Parameter menu, must be equal to zero: the above issue cannot be resolved simply by setting start-time at a higher value. Therefore, to tackle this problem [84] it is necessary to initialize simState to STOP or PAUSE through the RTI Simulation Options page of Simulink Configuration parameters menu; after building and downloading the model as usual, it is necessary to connect a Radio Button (or other similar instruments) to the simState variable using the values given in Table 5.14. After you start measuring in dSPACE CD, you can manually switch simState to RUN , allowing it to properly capture the behavior of the model at simulation start. But despite this, some data points in the measured signals could be lost: to achieve a continuous data acquisition without gaps, you have to activate the continuous mode by selecting Activate Continuous Mode (Disables triggers) from the context menu of the platform in dSPACE CD [85]. 80


5.3.2 dSPACE Profiler Employment Profiler is the tool provided by dSPACE to measure the duration of user-defined events, as described in Subsection 3.2.4. dSPACE Profiler is very useful since it also allows to evaluate the execution time of single Simulink subsystems. In fact, the measuring of the execution time of subsystems can be simply achieved by defining the appropriate events in the real-time program and then using dSPACE Profiler to measure their duration. In the referred analysis dSPACE Profiler is thus used to measure the execution time of the soft-constrained NMPC-PDIP solver. In order to achieve this goal, it is necessary to adhere to the following instructions [75], [76]:

1. In the user C file of the Simulink project (sc_NMPC_PDIP_usr.c) go to the function usr_initialize() and add the following code to setup and define a new event:

1. 2. 3. 4. 5. 6. 7. 8. 9.

static void usr_initialize(void){ unsigned int display_id; /*Define a line labelled "Event" that will show up in the Profiler*/ display_id = elog_define_display("Event"); /* Describe a start event, with "US" name (User Event Start) */ elog_describe_event(101, display_id, ELOG_CTRL_BLOCK_START | ELOG_CTRL_BLOCK_STATIC , 0, 0, "US");

10. 11. 12. . 13.

/* Describe a start event, with "UE" name (User Event End) */ elog_describe_event(102, display_id, ELOG_CTRL_BLOCK_END | ELOG_CTRL_BLOCK_STATIC , 0, 0, "UE"); }

Figure 5-31: Define new Profiler event

2. In the Simulink, model mark the NMPC-PIDP block as atomic (in general, it is possible both to create an Atomic Subsystem and put the model parts to be measured inside of it, or use an existing subsystem and mark it as atomic). It is very important to underline that the Atomic Subsystem alters the execution of the real-time code: 81


the generated code for the Atomic Subsystem does not interleave with code generated for blocks placed outside of it. This means that the corresponding task cannot be preempted, although, in our project, this situation is in any case guaranteed since dSPACE RTI employs single timer task mode to execute the real-time model.

3. In the Atomic Subsystem, add a System Output Block; then double-click the added block and edit its fields, as follow:

1. 2. 3. 4.

/*Declaration Code*/ elog_data_type event_data; event_data.high = 0; event_data.low = 0;

Figure 5-32: Profiler – System Outputs Declaration Code

1. 2. 3. 4.

/*Profiler Start Event:*/ /*write the start event, assigned to category 17*/ /*this code is generated at the beginning of the subsystem output code*/ ELOG_ENTRY_SET(101 | ELOG_CAT_17 , &event_data);

Figure 5-33: Profiler – System Output Function Execution Code

1. 2. 3. 4.

/*Profiler Stop Event:*/ /*write the stop event, assigned to category 17*/ /*this code is generated to the end of the subsystem output code*/ ELOG_ENTRY_SET(102 | ELOG_CAT_17 , &event_data);

Figure 5-34: Profiler – System Outputs Function Exit Code

4. Build and load the Simulink model as usual.

5. Open the dSPACE Profiler, open or create a new project, and select the event categories you are interested in, obviously including category 17.

dSPACE Profiler is now ready for profiling the execution time of the NMPC solver. 82


Figure 5.35 shows the structure of the profiled data for every test case (for a total of 120 samples), whereas Figure 5.36 shows the structure of the single sample.

. ..

Figure 5-35: Structure of the Profiled Data

(a) First Half of the Profiled Sample

(b) Second Half of the Profiled Sample

. . ....

. . ..

Figure 5-36: Structure of the Profiled Sample

83


The diagram shown in Figures 5.35 and 5.36 is composed of 3 rows:

1. The first row of the diagram, which is called Event, displays the information about the execution time of the NMPC-PDIP solver. US acronym stands for User timespan Start and it denotes the beginning of the observed time interval, whereas UE acronym stands for User timespan End and it denotes the end of the observed time interval.

2. The second row of the diagram, which is called RTK, displays the information about dSPACE RTK: it shows the time required by RTK to handle the interrupt signals and manage all the required resources. IE acronym stands for Interrupt Entry and it denotes the moment when the request signal for the execution of the task reaches the Operating System, whereas IX acronym stands for Interrupt Exit.

3. The third row of the diagram, which is called Timer Task 1, displays the information about the execution time of the only Timer Task of the considered real-time model. TR acronym stands for Task Registration, TE acronym stands for Task Entry, whereas TX acronym stands for Task Exit.

It is clear that dSPACE Profiler is an essential tool for the emulation analyses: it extracts time intervals which (almost) exactly match the execution times of the NMPC-PDIP solver, despite that the execution of the blocks placed in Timer Task 1 could be concurrent and DS1005 is not a multiprocessor system. In fact, dSPACE Profiler measures only a section of the execution time of Timer Task 1: the handling interrupt time and the execution time of the other blocks placed in Timer Task 1 are not included, as shown in Figure 5.36. This is further confirmed by using the Atomic Subsystem: as already mentioned, the generated code for the Atomic Subsystem does not interleave with code generated for blocks placed outside of it. Therefore, it could be assumed that it is not necessary to test the vehicle model task and the controller task on a Multiprocessor 84


System, since the execution time obtained by using dSPACE Profiler corresponds with the execution time of only NMPC-PDIP solver (it would be useful to confirm this hypothesis by using another Atomic Subsystem on vehicle model task, in order to verify via dSPACE Profiler the relationship between the two tasks). After all, since dSPACE RTI uses the single timer task mode in the project under consideration, the Overrun situation could happen even though the execution time of the solver does not exceed the given sampling time. In fact, the overrun happens when the execution time of the entire Timer Task 1, which includes the NMPC-PDIP and other Simulink blocks, exceeds the sampling time (as described in Subsection 3.2.3). In order to prevent this problem, on the contrary, it is necessary to use a Multiprocessor System, which may be obtained by using DS910 Gigalink Module and additional DS1005 boards.

5.4 Procedure for Profiling After employing the activities described in the previous section, the data measurement can be carried out. First of all, open the right project and then select the right experiment in dSPACE CD and dSPACE Profiler, and engage dSPACE CD by clicking the Go Online button. For each test case, set according to Table 5.15; , and 4

to

and

parameters by Numeric Input instruments

is calculated by adding an increment of

,

,

.

delta_in (degree) 2 3 4 5 6 7 8 9 10

Table 5-15: Test Plan – Steering angle

V_max (m/s) 26,24 21,40 18,51 16,54 15,07 13,93 13,01 12,24 11,59

and Maximum Velocity 85


After setting the input parameters, press Record Immediate on dSPACE Profiler, allowing it to display the measured time intervals on the timeline window and create the profile; then press Start Measuring on dSPACE CD, allowing it to measure the signals previously added to the measurement signal list.

Wait until you see the Recording note on the bottom right corner of dSPACE CD User-Interface, and then set simState to RUN in order to start the emulation test. When the test finishes, press Stop Profiling on dSPACE Profiler, and then press Stop Measuring on dSPACE CD. Close the ControlDesk NG popup window in dSPACE CD and proceed to next test.

Figure 5-37: dSPACE ControlDesk Toolbar

Figure 5-38: dSPACE Profiler Toolbar . .

For each test case, the data collected by dSPACE Profiler can be exported into a CSV file; this file contains the execution times of the NMPC-PDIP solver per call and other data: it is therefore necessary to use a script to extract the useful information and save them in a Matlab file. The data captured by dSPACE CD can be directly saved as a .mat file instead.

86


5.5 Emulation (SIL simulation) Results In the current Section, the author presents the results regarding the computational times required by solver in Subsection 5.5.1, the comparison between the simulated and the emulated soft-constrained NMPC-PDIP controllers in Subsection 5.5.2, and all other results in Subsection 5.5.3. For a complete description of all test cases, see Appendix B. 5.5.1 Solver Execution Times For each test case, the solver computational time per call is measured by dSPACE Profiler, whereas the iterations number performed by solver per call is measured by dSPACE CD. Since each iteration takes a fixed time, it is thus possible to approximately calculate the time required per iteration, for any sample, as the ratio between the controller computational time and the solver iterations number. On the basis of the information collected, the time

required by solver to perform one iteration is around computational time is approximately equal to

, whereas the maximum , which corresponds to the set

maximum number of 25 iterations that the solver can perform. In order to obtain more accurate results, you can subtract from the obtained time values the known time overheads, such as the overhead due to S-functions or User-Code, if any, or the dSPACE Profiler overhead described in Subsection 3.2.4. After all, this operation is useful only when a more detailed statistical analysis is carried out. Nevertheless, the first prerequisite for real-time implementing the NMPC is fulfilled: in every test case, also thanks to the cap in the maximum number of iterations, the maximum time required by solver per call to solve the NLP problem is smaller than the given NMPC sampling time

.

Figure 5.39 shows the execution time and the number of iterations performed by solver in Test Case 36 (steering angle = 10 degrees, V = 11,59 m/s + 4 m/s), where the maximum number of iterations is reached by solver multiple times.

87


Figure 5-39: Test Case 36 - Solver Execution Time and Number of Iterations

As mentioned before, a more detailed statistical analysis could be employed. After collecting sufficient data, this analysis allows us to understand how the data relates to the underlying population, and characterises all the SIL simulation results by the appropriate index of central tendency, such as the mean, median, and mode, and the appropriate index of dispersion, such as the variance. This analysis also provides several advantages, such as the possibility to accurately identify outliers. The outliers are atypical observations that are not caused by a real system phenomenon: for this reason, these observations should be ignored, since their use in results may significantly change the analysis’ conclusions. For example, in the emulation analysis to which we are referring, an outlier occurs in Test Case 21 (as can be seen in Figure 5.40): sample number 94 is characterised by a computational time around 50 ms, which corresponds to the given sampling time, even though the solver performs only 19 iterations (let us remember that 25 iterations correspond with an execution time around to 43,5 ms). Therefore, this value should be ignored since it subverts the results of the SIL simulation. In Figure 5.41 the maximum computational time for each test case is shown, clearly taking into account outliers (although the exclusion of the suspected outliers is based only on intuition). 88


Figure 5-40: Test Case 21 – Example of Outlier

Figure 5-41: Maximum Computational Time for each Test Case 89


5.5.2 Comparison between Simulation and Emulation Results As illustrated in Subsection 5.5.1, the maximum time required by solver per call in every test case is smaller than the given sampling time. On the other hand, the real-time implementability of the soft-constrained NMPC-PDIP is not yet guaranteed because the controller performance has not yet been analysed in emulation. Moreover, the cap in the maximum number of iterations that the solver can perform surely deteriorates controller performance; for this reason too, it is therefore necessary to compare simulation and emulation (SIL simulation) results in order to evaluate whether the controller exhibits an acceptable performance level on real-time HW. For each SIL simulation test case carried out through dSPACE CD, we take into account the velocity, yaw rate and longitudinal slip time histories, which are compared with time histories previously obtained in Simulink simulation.

Figure 5-42: Test Case 36 – Time histories Comparison [5]

90


As also confirmed in [5], the loss in performance is less than someone would expect: also in Test Case 36, where the maximum number of iterations is reached by solver multiple times, the velocity, yaw rate and longitudinal slip time histories for the controller deployed on dSPACE remain close to the trajectory obtained in simulation on desktop machine (in simulation, the maximum number of 200 iterations is never reached).

On the basis of the obtained results, we can say that dSPACE SIL simulation has been successful. Therefore, since SIL simulation results are adequate, it is now possible to employ a dSPACE HIL simulation, as explained in Section 3.3.

5.5.3 Further Results FORCES Pro automatically produces some information about solver characteristics: in detail, it creates a text file containing information concerning solver code memory consumption. The solver code of the control scheme, for which reference is made, is characterized by the properties listed in Table 5.16:

Data memory consumption

(statically allocated)

Code memory consumption Computation count

per interior-point iteration

Table 5-16: Soft-Constrained NMPC-PDIP solver code information

The above data are clearly not useful in SIL simulation since no information about the ECU to employ is yet considered. After all, information about solver code memory consumption will be useful in subsequent analyses: if you know the characteristics of the ECU to employ, the above information could be used, for example, to verify whether the ECU memory requirements are satisfied. Also dSPACE Profiler leads to information about performance, threads, and memory allocations/mappings of tested application: unfortunately, this feature is only available if using dSPACE SALEXIO target platform. 91


5.6 Benchmarking It might be helpful to carry out a performance characterization of the system used for the emulation, in order to enable the comparison between this and other systems. Clearly, the system performance characterization might be really difficult, since it is necessary to take into account many different factors; to simplify this analysis, only the characteristics of the system Central Processing Unit (CPU) could be considered. The computational performance of the CPU could be measured by using FLOPS, acronym for Floating Point Operation Per Second, which is often used for measuring the performance of supercomputers. FLOPS can be calculated using equation 5.20.

(5.20)

After all, Formula 5.20 does not provide accurate results since it does not consider the other characteristics of the CPU, such as the memory bandwidth and cache (see Figure 5.43), and it assumes that the CPU always completes the maximum number of operations per cycle. Therefore, the above formula simply provides a nominal value that represents the theoretical maximum performance level achievable by the CPU.

More useful results can be obtained by using a Benchmarking, since this process allows us to compare the performance level between two or more systems when they perform the same specific application. This can be done by using synthetic workloads, that are called benchmarks: obviously, the used workload must be representative of the real application; it is therefore necessary, for this reason, to accurately choose the benchmark to use. A benchmark belonging to the SPEC Benchmark Suite could probably be used to characterize the performance of the CPU employed by dSPACE board when it performs the emulation of the NMPC, since SPEC benchmarks are meant for comparing CPU speeds and they primarily stress the Floating Point Unit (FPU) of the systems. 92


Figure 5-43: Performance Experiments with Matrix Multiplication [87]

In order to choose the right benchmark, it is thus necessary to delineate the type and the number of the operations (I/O operations, floating-point operations, integer operations, etc.) performed by the soft-constrained NMPC-PDIP which reference is made. Only in this way, we will be able to select the appropriate benchmark and then obtain information which allows us to compare the performance level of the emulation target platforms (taking into account only information about CPU) when they perform the emulation of an NMPC-PDIP.

93


Conclusions This thesis project presented how to perform the SIL Simulation of an NMPC on a dSPACE platform, using the soft-constrained NMPC-PDIP developed by Siampis [5] as a case study. This control strategy, that was already analysed in simulation, is used for stabilisation of an Electric Vehicle at the limits of handling. SIL Simulation, that is a particular type of emulation, was used to assess the implementability of the NMPC in a real-time environment, since it allows us to obtain performance parameters which cannot be evaluated by performing the other phases of the NMPC testing process, like simulation. Nevertheless, nowadays in the scientific literature, not often can you find proofs of automotive NMPC testing activities that reach the emulation test phase.

More specifically, dSPACE SIL Simulation was used both to confirm the results obtained in the previous analyses and assess whether the NLP problem of the NMPC can be solved within the desired sampling period. On the basis of the results obtained, you realize that the NMPC is very demanding in terms of required computational power, but, despite this, the controller can be successfully deployed on a real-time HW with minimal performance loss, even for the extreme test cases considered. Factors that significantly influence the emulation results and allow a successful NMPC deployment undoubtedly are: the employment of a suitable development process, a proper design of the vehicle model and control strategy, and a good choice of the solver and target platform. In the present case, also the setting of a limit on the maximum number of iterations that the solver can perform lead to the NMPC real-time implementability, although it deteriorates controller performance. 94


As described above, the work carried out so far is really important, especially considering the small number of Automotive-NMPC testing activities that reach the emulation stage. However, the SIL simulation is just the first step in the NMPC testing activity in a real-time environment, that includes the HIL Simulation and eventually the Prototype Testing (or a real-vehicle testing).

95


Further Work The work presented in the thesis can be extended to:



Perform the successive stages of the NMPC testing activity. In fact, following the SIL Simulation, it is possible to employ an HIL simulation that allows you to progressively replace parts of the real-time simulation model with real-time components. This particular type of emulation can be used both to see how the proposed NMPC strategy performs on a real system in a completely safe test environment, and to assess other aspects of the controller: for example, HIL allows to verify whether the ECU memory requirements can be satisfied, or estimate deterioration of controller’s performance due to CAN delays. Following this, a Prototype Testing could eventually be performed.



Perform a Design of Experiment (DOE), in order to separate out the effects of various factors that might affect the NMPC performance, determine if the considered factors and their interactions have a significant effect on performance, and estimate experimental errors. With reference to simulation and emulation tests, we could consider as factors the steering input and the initial velocity of the vehicle; however, this analysis could also take into consideration the used dSPACE boards and the employed NMPC solvers as factors. DOE also allows us to determine if the considered factors have a significant effect on performance by comparing factor contribution to the variation with that of the error.

96




Modify and integrate vehicle model with other components and/or modify the test conditions (for example by introducing acceleration/deceleration command from the driver) in order to model a more realistic test environment.

97


98


Appendix A: DS1005 PPC Board – Technical Details

Table A-17: DS1005 Power PC Board – Technical Details [81]

99


DS1005 employs an IBM PowerPC 750GX Reduced Instruction Set Computer (RISC) Microprocessor [86], that is a 32-bit implementation of the PowerPC Architecture in a CMOS technology, designed for high performance and low power consumption. The high-performance of the considered microprocessor is due to its superscalar architecture, that allows for executing more than one instruction within a single clock cycle by using several independent execution units. Thanks to the superscalar architecture, in 750GX (i) as many as four instructions can be fetched from the instruction-cache per clock cycle, (ii) as many as two instructions can be dispatched and completed per clock, and (iii) as many as six instructions can be executed per clock (including two integer instructions). 750GX is equipped with 2 register files and 6 execution units:



One Branch Processing Unit (BPU), using both static and dynamic branch prediction.



One System Register Unit (SRU), that handles miscellaneous instructions.



One pipelined Load/Store Unit (LSU), which operates in 2 successive stages.



One pipelined Florating Point Unit (FPU), which breaks its tasks into subtasks and executes them in 3 successive stages.



Two Integer Units (IUs): IU1 executes all integer instructions, whereas IU2 executes all integer instructions except multiply and divide instructions.

The possibility of using simple instructions, in accordance with RISC architecture, and the ability to execute several instructions in parallel, thanks to the superscalar architecture, yield high efficiency and throughput for DS1005 board and every 750GX-based system. The above-mentioned microprocessor is also characterized by separate on-chip 32-KB L1 instruction and data caches (in accordance with Harvard architecture, that provides high performance by concurrent instruction and data access), and an integrated 1-MB L2 cache; it is also equipped with separate Memory Management Units (MMUs) for instruction and data, and an enhanced 60x bus interface (a basic interface for many variants of Motorola processor). Moreover, 750GX employs a Power and Thermal management for reducing power consumption. 100


Figure A-44: IBM Power PC 750GX RISC Microprocessor Block Diagram [86] 101


Appendix B: Emulation - Detailed Results Appendix B illustrates in detail all the results obtained through dSPACE SIL Simulation. Table B.18 is a test cases summary, whereas Table B.19 and Figure B.81 summarise maximum computational times of all test cases.

Vincr = 1 m/s

Vincr = 2 m/s

Vincr = 3 m/s

Vincr = 4 m/s

δ = 2 degree, Vmax = 26,24 m/s

TEST CASE 1

TEST CASE 2

TEST CASE 3

TEST CASE 4


TEST CASE 5

TEST CASE 6

TEST CASE 7

TEST CASE 8


TEST CASE 9

TEST CASE 10

TEST CASE 11

TEST CASE 12


TEST CASE 13

TEST CASE 14

TEST CASE 15

TEST CASE 16


TEST CASE 17

TEST CASE 18

TEST CASE 19

TEST CASE 20


TEST CASE 21

TEST CASE 22

TEST CASE 23

TEST CASE 24


TEST CASE 25

TEST CASE 26

TEST CASE 27

TEST CASE 28


TEST CASE 29

TEST CASE 30

TEST CASE 31

TEST CASE 32


TEST CASE 33

TEST CASE 34

TEST CASE 35

TEST CASE 36

Table B-18: SIL Simulation Test Cases

102


(a) Solver Execution Time and Number of Iterations

(b) Time histories Comparison

Figure B-45: Test Case 1 – Steering Angle = 2 degree, V = 26,24 m/s + 1 m/s 103
































































































































Figure B-77: Test Case 33 – Steering Angle = 10 degree, V =11,59 m/s + 1 m/s 135














Vincr = 1 m/s

Vincr = 2 m/s

Vincr = 3 m/s

Vincr = 4 m/s


40,07658 ms

38,40756 ms

38,42757 ms

38,44140 ms


36,73032 ms

43,42665 ms

43,46154 ms

40,08039 ms


43,32132 ms

39,91140 ms

40,06344 ms

41,71317 ms


43,41294 ms

41,72562 ms

43,41876 ms

43,43976 ms


43,29999 ms

41,73336 ms

41,78148 ms

43,43484 ms


43,42512 ms

43,42257 ms

43,46184 ms

43,46436 ms


43,43709 ms

43,46007 ms

43,45086 ms

43,48545 ms


43,34247 ms

43,29450 ms

43,46985 ms

43,48191 ms


43,37973 ms

43,43694 ms

43,47864 ms

43,52862 ms

Table B-19: Maximum Computational Time for each Test Case

Figure B-81: Maximum Computational Time for each Test Case

139


Appendix C: Primal-Dual Interior Point Method The Interior Point Methods, often referred as IPMs, are a particular class of algorithms that are used to solve both LP and NLP problems [88]. Of course, IPMs have the great merit of unifying optimization areas that have always been treated separately. As the name suggests, an IPM moves through the interior of the feasible region until it reaches the optimal solution of the problem; for this reason, IPMs stand in opposition to Active Set strategies (such as the Simplex method that even now dominates the LP field). Generally, four basic steps characterise any IPM [89]: (i) transforming the optimization problem with inequality constraints into an optimization problem with equality constraints, (ii) using a logarithmic barrier function, (iii) setting first-order optimality conditions, (iv) applying Newton’s method. Given its characteristics, the IPM is today deemed one of the most efficient methods to solve many types of optimization problems.

We can find the first evidence of an IPM algorithm in 1955 [91], even though the modern era of interior-point methods started in 1983 with the publication of Karmarkar’s paper [92], that introduced an efficient IPM for LP. Today, the most widely used IPM algorithm is undoubtedly Merhotra’s predictor-collector algorithm, which is an improved version of the original algorithm presented in 1992 [93]: it is used for most of the software implementations of these classes of methods.

The Interior Point Methods are often referred to as Barrier Point methods since they use a barrier function to obtain an unconstrained problem from the constrained one, and ensure 140


that almost all iterates remain in the interior of the feasible region [90]. A well-known barrier function is logarithmic function, which is characterized by a barrier parameter µ. Normally, any IPM solves the optimization problem through inner and outer iterations [94]. The inner iterations are used to minimize the cost function for a given µ by using Newton’s Method: the objective is to find the point

that satisfies the KKT optimality condition.

The outer iterations are used for convergence test and for decreasing µ. In fact, each inner iteration considers an optimization problem which is an approximation of the original one: the quality of these approximations increases when µ decreases. Nowadays, Primal-Dual Interior Point (PDIP) method is considered one of the most efficient IPM: as in the classical Barrier method, PIDP is based on inner and outer iterations, and it uses Newton’s method to solve the optimization problem. In addition, the dual problem and its dual variable λ are introduced: the objective of each PDIP inner iteration is thus to find (

) satisfying the optimality conditions. Once again, the outer iteration is used for

convergence test and for the adjustment of the barrier parameter µ. PDIP method is more efficient than the classical Barrier method since the primal-dual method allows to more efficiently follow the central path of the problem, which is defined as the sequence of points that converges to the optimal solution. Moreover [95]: (i) PDIP method can start at infeasible point, (ii) and cost per iteration is the same as classical Barrier method.

Theoretically, IPMs exhibit polynomial complexity whereas Active Set methods exhibit exponential complexity [34]. Despite this, both Active Set strategies and IPM strategies have advantages and drawbacks [48]. As confirmed in [34],[96], IPMs are advantageous for constrained problems with long horizons and many degrees of freedom, since they are largely insensitive to the number of active constraints; in addition, IPMs benefit from the sparsity structure of MPC problems. On the other hand, as can be seen from [97], Active Set strategies are advantageous if the optimization problem is characterized by few active constraints: with IPMs, the factorization of the KKT matrix is really expensive in any case since it does not take into account the number of active constraints.

141

142

References [1]

C. R. Cutler and B. L. Ramaker, Dynamic matrix control - a computer control

algorithm, Proc. Joint Automatic Control Conf., San Francisco, CA, 1980. [2]

W.M. Canney, Are you getting the full benefit from your advanced process control

system? Hydrocarbon Processing 84(6), 55–58, 2005 [3]

M. Bauer, I.K. Craig, Economic assessment of advanced process control – A survey

and framework, Journal of Process Control 18, 2–18, 2008 [4]

R. Findeisen, F. Allgöwer, An Introduction to Nonlinear Model Predictive Control,

21st Benelux Meeting on Systems and Control, 2002 [5]

E. Siampis, Optimal torque vectoring control strategies for stabilisation of electric

vehicles at the limits of handling, 2016, http://dspace.lib.cranfield.ac.uk/handle/1826/11777 [6]

A. Domahidi and J. Jerez, FORCES Professional, embotech GmbH

(http://embotech.com/FORCES-Pro), Jul. 2014. [7]

S.J.Qin, T.A.Badgwell, A survey of industrial model predictive control technology,

Control Engineering Practice 11, 733–764, 2003 [8]

J.H.Lee, Model Predictive Control: Review of the Three Decades of Development,

International Journal of Control, Automation, and Systems 9(3), 415-424, 2011 [9]

M.Morarim J.H.Lee, Model predictive control: past, present and future, Computers

and Chemical Engineering 23, 667–682, 1999 [10] T.M.Scout, T.J.Williams, Pioneering work in the field of computer process control, IEEE Annals of the history of Computing 17(1), 20-26, 1995 [11] M.V.Long, E.G.Holzmann, Approaching the Control Problem of the Automatic 143

Chemical Plant, Transactions of ASME, 1953 [12] R.E.Kalman, Contributions to the theory of optimal control, Bulletin de la Societe Mathematique de Mexicana, 5, 102-119, 1960 [13] R.E.Kalman, A new approach to linear filtering and prediction problems, Transactions of ASME, Journal of Basic Engineering, 87, 35-45, 1960 [14] J.Richalet, A.Rault, J.L.Testud, J.Papon, Algorithmic control of industrial processes, Proceedings of the 4th IFAC symposium on identification and system parameter estimation, 1976, 1119-1167 [15] C.E.Garcìa, D.M.Prett, M. Morari, Model predictive control : Theory and practice – a survey, Automatica, 25(3), 335-348, 1989 [16] J.Richalet, A.Rault, J.L.Testud, J.Papon, Model predictive heuristic control : Applications to industrial processes, Automatica, 14, 413-428, 1978 [17] C.R.Cutler, B.L.Ramaker, Dynamic matrix control – a computer control algorithm, AICHE national meeting, Houston, TX, April 1979 [18] D.M.Prett, R.D.Gillette, Optimization and constrained multivariable control of a catalytic cracking unit, Proceedings of the joint automatic control conference [19] C.Cutler, A.Morshedi, J.Haydel, An industrial perspective on advanced control, AICHE annual meeting, Washington, DC, October 1983 [20] C.E.Garcia, A.M.Morshedi, Quadratic programming solution of dynamic matrix control (QDMC), Chemical Engineering Communications, 46, 73-87 [21] P.Grosdidier, B.Froisy, M.Hammann, The IDCOM-M controller. In T.J.McAvoy, Y.Arkun, E.Zafiriou (Eds.), Proceedings of the 1988 IFAC workshop on model-based process control. Oxford : Pergamon Press, 31-36, 1988 [22] J.B.Froisy, T.Matsko, IDCOM-M application to the Shell fundamental control problem, AICHE annual meeting, November 1990 [23] P.Marquis, J.P.Broustail, SMOC, a bridge between state space and model predictive controllers: Application to the automation of hydrotreating unit, In T.J.McAvoy, Y.Akrun, E.Zafiriou (Eds.), Proceedings of the 1998 IFAC workshop on model based process control. Oxford: Pergamon Press, 37-43 144

[24] C.Yousfi, R.Tournier, Steady-state optimization inside model predictive control, Proceedings of ACC’91, Boston, MA, 1866-1870, 1991 [25] Wikipedia, Robust Control, https://en.wikipedia.org/wiki/Robust_control, 2017 [26] P.J.Campo, M.Morari, Robust model predictive control, Proc. Of the American Control Conference, 1021-1026, 1987 [27] J.C.Allwright, G.C.Papavasiliou, On linear programming and robust modelpredictive control using impulse-responses, Systems and Control Letters, 18, 159-164, 1992 [28] J.H.Lee, Z.Yu, Worst-case formulation of model predictive control for systems with bounded parameters, Automatica, 33(5), 763-781, 1997 [29] M.V.Kothare, V.Balakrishnan, M.Morari, Robust constrained model predictive control using linear matrix inequalities, Automatica, 32(10), 1361-1379, 1996 [30] A.Bemporad, M.Morari, Control of systems integrating logic, dynamics, and constraints, Automatica, 35(3), 407-427, 1999 [31] A.Bemporad, M.Morari, V.Dua, E.N.Pistikopoulos, The explicit linear quadratic regulator for constrained system, Automatica, 38(1), 3-20, 2002 [32] A.Bemporad, F.Borrelli, M.Morari, Piecewise linear optimal controllers for hybrid systems, Proc. Of American Control Conference, Chicago, IL, 1190-1194, 200 [33] Y.Wang, S.Boyd, Fast Model Predictive control using online optimization, IEEE Transactions on Control System Technology, 18(2), 267-278, 2010 [34] C.V.Rao, S.J.Wright, J.B.Rawlings, Application of interior-point methods to model predictive control, Journal of Optimization Theory Application, 99, 723-757, 1998 [35] E.B.Lee, L.Markus, Foundations of optimal control theory, Wiley, New York, NY, 1967. [36] H.Chen, F.Allgower, A quasi-infinite horizon nonlinear predictive control scheme for stable systems: application to a CSTR, Proc. IFAC Symp. on Advanced Control of Chemical Processes, Banff, Canada, 471-476, 1997 [37] D.Q.Mayne, H.Michalska, Receding horizon control of nonlinear systems, IEEE Trans. Automat. Control, AC-35, 814-824, 1990 [38] A.Zheng, A computationally efficient nonlinear MPC algorithm, Proc. American 145

Control Conf., Albuquerque, NM, 1623-1627, 1997 [39] T.A.Badgwell, A robust model predictive control algorithm for stable nonlinear plants, Proc. IFAC Symposium on Advanced Control of Chemical Processes, Banff, Canada, 477-481, 1997 [40] C.Tricaud, Y.Q.Chen, Linear and Nonlinear Model Predictive control using a general purpose optimal control problem solver RIOTS_95, Control and Decision Conference, 2008 [41] M.Fruchard, G.Allibert, E.Courtial, Choice of the control horizon in an NMPC strategy for the full-state control of nonholonomic systems, American Control Conference (ACC), 2012 [42] Ton J.J. van den Boom, Infinite-Horizon Model Predictive Control with structured input signals, Proceedings of the American Control Conference, Anchorage, Ak, 2002 [43] M.A.Henson, Nonlinear model predictive control: current status and future directions, Computers and Chemical Engineering 23, 187-202, 1998 [44] J.W.Chinneck, Practical Optimization: a gentle introduction, 2012 [45] B.W.Bequette, Nonlinear control of chemical processes: a review, Ind. Engng Chem. Res., 30, 1391-1413, 1991 [46] E.S.Meadows, J.B.Rawlings, Model predictive control, In M.A.Henson, D. E. Seborg (Eds). Nonlinear process control, Chapter 5, 233-310, Englewood Cliffs, NJ: Prentice-Hall. [47] A.Zheng, A computationally efficient nonlinear MPC algorithm, Proc. American Control Conf., Albuquerque, NM, 1623-1627, 1997. [48] R.A.Bartlett, A.Wachter, L.T.Biegler, Active Set vs. Interior Point strategies for model predictive control, Proceedings of the American Control Conference, Chicago, Illinois, 2000 [49] T.L.McKinley, A.G.Alleyne, Adaptative Model Predictive Control of an SCR catalytic converter system for automotive applications, IEEE Transactions on Control Systems Technology, 20(6), 1533-1547, 2012 [50] M.Herceg, T.Raff, R.Findeisen, F.Allgower, Nonlinear Model Predictive Control of 146

a turbocharged diesel engine, Proceedings of the 2006 IEEE International Conference on Control Applications, Munich, Germany, 2006 [51] S.Trimboli, S.Di Cairano, A.Bemporad, I.V.Kolmanovsky, Model predictive control for automotive time-delay processes: An application to air-to-fuel ratio control, IFAC Proceedings Volumes. 42(14), 90-95, 2009 [52] H.Chen, S.Yu, X.Lu, F.Xu, T.Qu, F.Wang, Applying Model Predictive Control in automotive, Proceedings of the 10th World Congress on Intelligent Control and Automation, Beijing, China, 2012 [53] D.Bernardini, S.Di Cairano, A.Bemporad, H.E.Tseng, Drive-by-wire vehicle stabilization and yaw regulation: a Hybrid Model Predictive Control design, Joint 48th IEEE Conference on Decision and Control and 28th Chinese Control Conference, Shanghai, P.R.China, 2009 [54] C.E.Beal, J.C.Gerdes, Model Predictive Control for vehicle stabilization at the limits of handling, IEEE Transaction on Control Systems Technology, 21(4), 1258-1269, 2013 [55] S.Li, K.Li, R.Rajamani, J.Wang, Model predictive multi-objective vehicular adaptative cruise control, IEEE Transactions on Control Systems Technology, 19(3), 556-566, 2011 [56] M.G.Plessen, D.Bernardini, H.Esen, A.Bemporad, Spatial-based predictive control and geometric corridor planning for adaptive cruise control coupled with obstacle avoidance, IEEE Transactions on Control Systems Technology, 2017 (?) [57] P.Falcone, F.Borrelli, J.Asgari, H.E.Tseng, D.Hrovat, Predictive active steering control for autonomous vehicle systems, IEEE Transactions on Control Systems Technology, 15(3), 566-580, 2007 [58] D.Hrovat, S.Di Cairano, H.E.Tseng, I.V.Kolmanovsky, The development of Model Predictive Control in Automotive industry: a survey, 2012 IEEE International Conference on Control Applications (CCA), Part of 2012 IEEE Multi-Conference on Systems and Control, Dubrovnik, Croatia, 2012 [59] B.Saerens, M.Diehl, J.Swevers, E.Van den Bulck, Model Predictive Control of automotive powertrains – First experimental results, Proceedings of the 47th IEEE 147

Conference on Decision and Control, Cancun, Mexico, 2008 [60] Md.A.S.Kamal, M.Mukai, J.Murata, T.Kawabe, Model Predictive Control of vehicles on urban roads for improved fuel economy, IEEE Transactions on Control Systems Technology, 21(3), 831-841, 2013 [61] S.Di Cairano, D.Yanakiev, A.Bemporad, I.V.Kolmanovsky, D.Hrovat, Model Predictive Control Idle Speed Control: design, analysis, and experimental evaluation, IEEE Transactions on Control Systems Technology, 20(1), 84-97, 2012 [62] S.Di Cairano, J.Doering, I.V.Kolmanovsky, D.Hrovat, MPC-based control of engine deceleration with Open Torque Converter, 51st IEEE Conference on Decision and Control, Maui, Hawaii, USA [63] G.Ripaccioli, D.Bernardini, S.Di Cairano, A.Bemporad, I.V.Kolmanovsky, A Stochastic Model Predictive Control approach for Series Hybrid Electric Vehicle power management, 2010 American Control Conference Marriott Waterfront, Baltimore, MD, USA, 2010 [64] H.Borhan, A.Vahidi, A.M.Phillips, M.L.Kuang, I.V.Kolmanovsky, S.Di Cairano, MPC-based energy management of a power-split Hybrid Electric Vehicle, IEEE Transactions on Control Systems Technology, 20(3), 593-603, 2012 [65] H.Esen, T.Tashiro, D.Bernardini, A.Bemporad, Cabin Heat thermal management in Hybrid Vehicles using Model Predictive Control, 2014 22nd Mediterranean Conference on Control and Automation (MED), University of Palermo, Palermo, Italy, 2014 [66] S.Di Cairano, H.E.Tseng, D.Bernardini, A.Bemporad, Steering Vehicle control by Switched Model Predictive Control, 6th IFAC Symposium Advances in Automotive Control, Munich, Germany, 2010 [67] S.Di Cairano, H.E.Tseng, D.Bernardini, A.Bemporad, Vehicle yaw stability control by coordinated Active Front Steering and Differential Braking in the tire sideslip angles domain, IEEE Transactions on Control Systems Technology, 21(4), 1236-1248, 2013 [68] S.D.Keen, D.J.Cole, Steering control using Model Predictive Control and multiple internal models, Proceedings of AVEC ’06, The 8th International Symposium on Advanced Vehicle Control, Taipei, Taiwan, 2006 148

[69] R.Jain, Art of computer systems performance analysis techniques for experimental design measurements simulation and modeling, Wiley Computer Publishing, John Wiley & Sons, Inc., 1991 [70] I.McGregor, The relationship between simulation and emulation, Proceedings of the 2002 Winter Simulation Conference, E. Yiicesun, C.-H. Chen, J. L. Snowdon. and J. M. Churnes, eds., 2002 [71] Rea-Time Workshop: For Use with SIMULINK, User’s Guide, Version 2.1 [72] Dr.P.Waeltermann, Hardware-in-the-Loop: The technology for testing electronic controls in vehicle engineering, www.dspace.com, 2017 [73] dSPACE Hardware-in-the-Loop testing systems, www.dspace.com, 2017 [74] Real-Time Interface: Implementation software for running models on dSPACE hardware, www.dspace.com, 2017 [75] Real-Time Interface (RTI and RTI-MP): Implementation Guide, Release 4.2, www.dspace.com, 2005 [76] dSPACE Profiler : Guide, Release 3.2, www.dspace.com, 2005 [77] E.Velenis, D.Katzourakis, E.Frazzoli, P.Tsiotras, R.Happee, Steady-state drifting stabilization of RWD vehicles, Control Engineering Practice, 19(11), 1364-1376, 2011 [78] E.Siampis, M.Massaro, E.Velenis, Electric rear axle torque vectoring for combined yaw stability and velocity control near the limit of handling, in Decision and Control (CDC), 2013 IEEE 52st Annual Conference, 2013 [79] E.Siampis, E.Velenis, S.Longo, Rear wheel torque vectoring model predictive control with velocity regulation for electric vehicles, Vehicle System Dynamics, 53(11), 1555-1579, 2015 [80] M.Vukov, R.Quirynen, M.Diehl, Fast solver for nonlinear optimal control and estimation, www.imtlucca.it/embopt-14/Slides/vukov.pdf , 2017 [81] DS1005 PPC Board - dSPACE flyer, www.dpsace.com , 2015 [82] J.Andersson, J.Åkesson, M.Diehl, CasADi - A symbolic package for automatic differentiation and optimal control, Recent Advances in Algorithmic Differentiation, 297-307, 2012. 149

[83] dSPACE ControlDesk Product information, www.dpsace.com , 2017 [84] Controlling Applications with the simState Variable - dSPACE FAQ 253, www.dspace.com, 2016 [85] Handling gaps in Data Measured with ControlDesk Next Generation – dSPACE FAQ 408, 2016 [86] IMV PowerPC 750GX and 750GL RISC Micro-processor – User’s Manual, version 1.2, 2006 [87] S.G.Johnson, Performance Experiments with Matrix Multiplication (MIT course 18.335 Fall 2008), 2008, https://math.mit.edu/~stevenj/18.335/matmuls.pdf [88] M.Glavic, L.Wehenkel, Interior Point Methods: A Survey; Short Survey of Applications to Power Systems, and Research Opportunities – Technical Report, 2004 [89] V.H.Quintana, G.L.Torres, Introduction to Interior-Point Methods, IEEE PES Task Force on Interior-Point Methods Application to Power Systems, 1997 [90] A.Geletu, Introduction to Interior Point Methods – TU Ilmenau, 2017 [91] K.R.Frisch, The logarithmic potential method of convex programming, Memorandum, University Institute of Economics, Oslo, 1955 [92] N.Karmarkar, A new polynomial-time algorithm for linear programming, Combinatorica, 4, 373-395, 1984 [93] S.Mehrotra, On the implementation of a primal-dual interior point method, SIAM J. Optim. 2, 575-601, 1992 [94] A.Forsgren, P.E.Gill, M.H.Wright, Interior Methods for Nonlinear Optimization, SIAM Rev., 44(4), 525-597, 2002 [95] J.P.Vert, Nonlinear Optimization; Algorithms 3: Interior-point methods, INSEAD Spring 2006, 2017 [96] J.S.Albuquerque, V.Gopal, G.H.Staus, L.T.Biegler, B.E.Ydstie, Interior point SQP strategies for structured process optimization problems, Computers & Chemical Engineering, 21, 853-859, 1997 [97] D.J.Ternet, L.T.Biegler, Interior-Point methods for reduced Hessian successive quadratic programming, Computers & Chemical Engineering, 23(7), 859-873, 1999 150

Ringraziamenti Ringrazio il Professor Sabato Manfredi per avermi dato questa possibilità, per non avermi mai fatto mancare il suo sostegno, e per i suoi preziosi consigli.

Grazie al Professor Stefano Longo, mia guida presso la Cranfield University.

Grazie a Stathis, che ha contribuito notevolmente alla realizzazione di questo progetto.

Un ringraziamento particolare a Roberto, grande esempio di umiltà.

Grazie alla mia famiglia, che sarà sempre il mio punto di riferimento. Che questo traguardo raggiunto, per quanto possibile, sia un riconoscimento anche per loro.

In ultimo, ma non per importanza, grazie ad Isabella, una persona attenta e premurosa, unica e speciale, per avermi accompagnato nell’ultimo tratto di questo straordinario cammino.

dSPACE Emulation of a Non-Linear Model Predictive ...

dSPACE Emulation of a Non-Linear Model Predictive ...

Suggest Documents

Nonlinear Model Predictive Control

RESEARCH ARTICLE A nonlinear model predictive ...

Nonlinear Model Predictive Control for

A Framework for Nonlinear Model Predictive Control

Policy Regularized Model Predictive Control ... - DSpace@MIT

Nonlinear Predictive Control of An Exothermic CSTR ... - DSpace@IITB

Comparative evaluation of nonlinear model predictive ...

Decentralized Nonlinear Model Predictive Control of

Robust Model Predictive Control of Nonlinear Affine

Constrained Nonlinear Model Predictive Control of

Nonlinear Model Predictive Control of a Thermal Management System

Nonlinear Model Predictive Control of a Cable-Robot

A Nonlinear Model Predictive Control of an Omni ... - CiteSeerX

Nonparametric nonlinear model predictive control - Core

Nonlinear Model-Predictive Control Based on Quasi

Nonlinear Model Predictive Control with Constraint

CRANFIELD UNIVERSITY Nonlinear Model Predictive Control ... - Core

Hierarchical Nonlinear Model-Predictive Ramp Metering ... - CiteSeerX

Hybrid Nonlinear Model-Predictive Control of a ... - IEEE Xplore

COMPUTATIONAL DELAY IN NONLINEAR MODEL PREDICTIVE ...

Experimental Nonlinear Model Based Predictive ... - Springer Link

Nonlinear Model Predictive Path-Following Control 1

Nonlinear Infinite Horizon Model Predictive Control

Nonlinear Stochastic Model Predictive Control Via