Czar Kowski 02 A

A Thesis
entitled
Multi-Core Implementation of F-16 Flight Surface Control System Using GA Based
Multiple Model Reference Adaptive Control Algorithm
by
Xiaoru Wang
Submitted to the Graduate Faculty as partial fulfillment of the requirements
for the Master of Science Degree in Electrical Engineering
_______________________________________
Dr. Mohsin M. Jamali, Committee Chair
_______________________________________
Dr. Mohammed Y. Niamat, Committee Member
_______________________________________
Dr. Hong Wang, Committee Member
_______________________________________
Dr. Patricia R. Komuniecki, Dean
College of Graduate Studies
The University of Toledo
May 2011
An Abstract of
Multi-Core Implementation of F-16 Flight Surface Control System Using GA Based
Multiple Model Reference Adaptive Control Algorithm
by
Xiaoru Wang
Submitted to the Graduate Faculty as partial fulfillment of the requirements

for the Master of Science Degree in Electrical Engineering
The University of Toledo

May 2011
This thesis first of all simulates previously developed F-16 flight surface control system
using direct Model Reference Adaptive Control (MRAC). It simulates all three rotation
motion controls such as pitch, roll and yaw. It then incorporates numerical solution of
differential equation using 4th order Runge-Kutta algorithm in the simulation. A Multiple
Model Reference Adaptive Control (MMRAC) with Genetic Algorithm (GA) based model
selection scheme has been proposed. The second part of this thesis is focused on
implementation of the proposed algorithm on a 4-core-Architecture of Intel® i5 CPU. The
sequential code was first written in C++ on .NET Framework 4. Parallel processing
approaches were exploited for parallelization of the GA based MMRAC algorithm. Several
optimization techniques were used to achieve the maximum speed up.
iii
Acknowledgements
I sincerely thank my advisor Dr. Mohsin Jamali for giving me the opportunity to pursue
my research under his guidance. It has been a great learning experience working with him. I
would like to express my deepest gratitude towards him for offering instructive advice at all
times, treating me with endurance, and constantly pushing me to do better every time. I
would also like to thank my thesis committee members Dr. Mohammed Y. Niamat and Dr.
Hong Wang for their enthusiastic guidance through this endeavor.
Last, but not the least, I thank my family, fiancé, and friends who have been a constant
source of encouragement and support for me throughout my journey in the Masters Degree
program.
v
Contents
Abstract…………………………………………………………………………………..iii
Acknowledgements………………………………………………………………………v
Contents………………………………………………………………………………….vi
List of Tables…………………………………………………………………………….ix
List of Figures……………………………………………………………………….…...xi
1. Introduction…………………………………………………………………………….1
1.1 Background .................................................................................................... 1
1.2 Research Approach ........................................................................................ 4
1.3 Organization................................................................................................... 4
2. Model Reference Adaptive Control (MRAC)…………………………………………6
2.1 Introduction to Adaptive Control .................................................................... 6
2.2 Definitions and Concepts................................................................................ 7
2.3 Examples of Adaptive Controller ................................................................... 8
2.4 Model Reference Adaptive Control (MRAC) ................................................. 9
2.4.1 Model-following.............................................................................................. 10
2.4.2 MIT rule ........................................................................................................... 12
2.4.3 Normalized MIT rule ..................................................................................... 13
2.4.4 A MRAC Example ......................................................................................... 14
3. F-16 Flight Surface Control Model 16
vi
3.1 F-16 Flight Model ........................................................................................ 16
3.2 Mathematical Model of F-16 Aircraft ........................................................... 19
3.2.1 MRAC controller of F-16 Aircraft ............................................................... 22
3.2.2 Structure of F-16 Aircraft Body and MRAC Control system .................. 24
3.3 Simulation Architecture................................................................................ 25
3.3.1 Simulation Model Building Blocks ............................................................... 26
3.3.2 MATLAB Flight Model ................................................................................. 26
3.3.3 Initial State of Pitch Rotation System .......................................................... 28
3.3.4 Initial State of Roll Rotation System ............................................................ 29
3.3.5 Initial State of Yaw Rotation System ........................................................... 30
3.4 MRAC based F-16 Flight Surface Control Simulation .................................. 31
3.4.1 Pitch Rate Control .......................................................................................... 31
3.4.2 Runge-Kutta 4th Order Method .................................................................. 32
3.4.3 Roll Control ..................................................................................................... 35
3.4.4 Yaw Control .................................................................................................... 36
4. Genetic Algorithm Based Multiple Model MRAC………………………………….38
4.1 Multiple-Model MRAC (MMRAC) .............................................................. 39
4.1.1 The need for MMRAC................................................................................... 39
4.1.2 Multiple-Model Reference Adaptive Control ............................................. 40
4.1.3 Model switching .............................................................................................. 41
4.2 Genetic Algorithm (GA) ............................................................................... 42
4.2.1 Basics of GA.................................................................................................... 42
vii
4.2.2 Why Genetic Algorithm ................................................................................ 46
4.3 GA based MMRAC ...................................................................................... 47
4.3.1 MMRAC mapping onto flight surface control ........................................... 47
4.3.2 GA mapping onto flight surface control system ....................................... 49
4.4 MMRAC Controlled flight surface control system simulation ...................... 50
5. Parallel Processing Using Multi-Core……………………………………………….56
5.1 Multi-core Architecture ................................................................................ 57
5.1.1 Advantage of Multi-core Computing........................................................... 57
5.1.2 Overhead behind Multi-core Computing ................................................... 59
5.1.3 Multi-core CPU............................................................................................... 60
5.2 F-16 Flight Surface Control System Simulation in C++ ................................ 60
5.3 Analysis of the C++ Code ............................................................................ 62
5.4 Restructure of Parallel Program .................................................................... 65
5.4.1 Cache hits and memory allocation ............................................................... 65
5.4.2 Increasing Parallelism by Reducing Repeated Processes ......................... 69
5.4.3 Other Possible Code Optimization Methods ............................................. 71
5.5 Performance of Optimized Parallel Program ................................................. 71
6. Conclusions and Future Work……………………………………………………….76
6.1 Conclusions .................................................................................................. 76
6.2 Future Work ................................................................................................. 77
References……………………………………………………………………………….78
viii
List of Tables
3-1 Relationship between Roll, Yaw, Pitch and Aileron, Elevator and Rudder ........................19
3-2 Degree limits of various deflections and actuators .................................................................20
3-3 Model parameters ........................................................................................................................21
3-4 Controller parameters .................................................................................................................23
3-5 Physical meanings of computational functions .......................................................................28
3-6 Initial State and Command Signals for pitch position tracking control ..............................29
3-7 Initial State and Command Signals for roll position tracking control .................................30
3-8 Initial State and Command Signals for yaw position tracking control ................................30
4-1 Yaw Rate and Throttle Command Value .................................................................................38
4-2 Parent selection ............................................................................................................................44
4-3 A new generation .........................................................................................................................38
4-4 GA model generator ...................................................................................................................48
4-5 Comparison of MSE for yaw control system ..........................................................................50
4-6 Comparison of MSE for pitch control system ........................................................................52
4-7 Comparison of MSE for roll control system ...........................................................................53
4-8 MSE comparison for three rotation control systems .............................................................54
5-1 Specifications of Intel® Core TM i5-520M ................................................................................59
5-2 Execution Time of Serial C++ Simulation ..............................................................................61
5-3 Execution Time of Parallelized single model MRAC C++ Simulation ..............................64
5-4 Execution Time of Optimized Parallel single model MRAC C++ Simulation .................71
ix
5-5 Execution Time of Optimized Parallel GA based MMRAC C++ Simulation ..................72
5-6 Comparison of execution time for different serial and parallel programs ..........................73
x
List of Figures
1-1 Structure of Model Reference Adaptive Control ...................................................................... 2
1-2 Structure of 4-CPU Architecture ................................................................................................ 3
2-1 Block diagram of basic MRAC controlled system ..................................................................10
2-2 A SISO system with a general regulator ...................................................................................11
2-3 Block diagram of a MRAC embedded system ........................................................................14
3-1 Aircraft 3-axis rotation (NASA) ................................................................................................17
3-2 Surfaces on an airplane (NASA) ...............................................................................................18
3-3 F-16 aircraft body system architecture .....................................................................................24
3-4 Computational flow of flight surface control ..........................................................................25
3-5 Simulation flow chart of MRAC based F-16 surface control system ..................................27
3-6 Pitch Rate control result using „ODE45‟ .................................................................................31
3-7 Comparison of pitch control with the function „ODE45‟ and the custom code ..............33
3-8 Magnitude between the pitch control tracking and the command signal ...........................33
3-9 Rate control result in comparison with the command pattern .............................................34
3-10 Error magnitude between the roll control tracking and the command signal..................35
3-11 Yaw rate control result in comparison with the command pattern ...................................36
4-1 Yaw control result under a new command signal ...................................................................38
4-2 Structure of MMRAC .................................................................................................................40
4-3 An example of one-time reproduction .....................................................................................42
4-4 An example of mutation under probability of 0.01 ................................................................43
xi
4-5 The crossover step ......................................................................................................................44
4-6 The mutation step .......................................................................................................................45
4-7 Block diagram of GA based MMRAC .....................................................................................47
4-8 GA based MMRAC yaw control ...............................................................................................49
4-9 Comparison between square-errors from normal MRAC and GA embedded MRAC for
yaw control .................................................................................................................................50
4-10 MMRAC embedded pitch control result ...............................................................................51
4-11 Comparison between square-errors from normal MRAC and GA embedded MRAC for
pitch control ...............................................................................................................................51
4-12 MMRAC embedded roll control result in comparison with command signal .................52
4-13 Comparison between square-errors from normal MRAC and GA based MRAC for roll
control .........................................................................................................................................53
5-1 Parallel Computation ..................................................................................................................57
5-2 Program partitioning process.....................................................................................................58
5-3 Pitch Control Tracking of GA based MMRAC system in C++ ..........................................60
5-4 CPU Usage of Serial Program ...................................................................................................62
5-5 CPU Usage of Parallel Program ................................................................................................63
5-6 Pyramid Data Storage .................................................................................................................65
5-7 Architecture of a calling Function.............................................................................................68
5-8 Snapshot of Execution Result ...................................................................................................71
5-9 Pitch tracking using serial and parallel programs ....................................................................73
xii
Chapter 1
Introduction
1.1 Background
A good system controller is known for its accurate response trajectory and fast
responding speed [1]. For highly non-linear time-variant systems, the desire for such a well-
performed controller grows even greater. Due to the complexity of systems such as flight
control, adaptive control first appeared in the early 1950s and proved its overwhelming
success in the 1980s [2]. The idea of adaptive control came from the researches of aircraft
systems [1].
The accuracy of the system response relies largely on the design of adaptive controllers
[3]. Among various adaptive control schemes, Model Reference Adaptive Control (MRAC)
is known for its accurate tracking of model and stable response process [1]. Therefore the
system controller will use MRAC based algorithm. A structure of such a system is given in
Figure 1.1. A model is pre-designed as a learning example. The controller and parameter
adjustment block modify the system parameters according to the model. As a result, the
system gets closer and closer to the model.
1
Pre-selected Parameter
Model Adjustment
U Controlled
Controller System
c
Figure 1.1: Structure of Model Reference Adaptive Control

Figure 1.1 shows only a simplified block diagram of a MRAC controlled system.
Sometimes a single model is not able to fully represent all the conditions under which the
system will be working [1]. Therefore number of models has to be designed along with a
switching system which keeps the system learning from different models according to
different conditions. Later in this thesis, a Multiple Model MRAC (MMRAC) controller and
a model selection scheme will be developed to further improve system performance.
The response time of the system on one hand depends on the converging speed of the
controller based on the of system designs; on the other hand, it will also depend on the
execution time of the program based on the real time performance of the control system.
The second part and the key section of this thesis are to speedup of the control system
program using parallel computing technology [4].
Modern processors cannot offer higher frequency or faster computer time according to
Moore‟s law. Processor manufactures have reached a road block and the way around this
road block is via multi-cores. Parallel computing has been revived and every processor
manufacturer is offering some kind of multi-core and parallel processing capability [5].
Parallel computing is a special form of execution in which many instructions are carried
out simultaneously. Large scale of computation can often be divided into smaller ones, as
processes, which are then solved concurrently. There are several different forms of parallel
2
processing: data-level, instruction level, loop level and functional level parallelism [4]. The
power consumption and consequently heat generation of the modern processors has
become an issue in recent years. Figure 1.2 shows a basic idea of 4-CPU architecture. As
Figure 1.2 shows, the program is saved in the main memory which is placed at the center of
the figure. There are four processors that are able to work together concurrently sharing the
main memory. The program is able to gain extra speedup if it is properly partitioned and ran
on all the CPUs in parallel.
CPU
CPU Memory CPU
CPU
Figure 1.2: Structure of 4-CPU Architecture

There are many multi-core platforms available besides traditional CPUs which include
GPUs and multi-unit microprocessors [4] [5].
Developments in the gaming industry are also leading revolution of Graphic Processing
Units (GPUs) [4]. Today, these GPUs can also be exploited for other math intensive
problems such as control, signal, image and other computational intensive processing. One
of the successful GPU example is Nvidia‟s Compute Unified Device Architecture (CUDA)
enabled GPU [4]. Nvidia has invented the CUDA parallel computing architecture that is
now being shipped in GeForce, ION, Quadro, and Tesla GPUs. Most CUDA enabled
GPUs nowadays have more than 400 cores that can be utilized to run mathematically
intensive programs in parallel [4].
3
IBM has introduced a multi-core processor called the Cell Broadband Engine (Cell BE)
processor [5]. The Cell BE processor is a nine-core processor which includes one Power
Processing Element (PPE), eight Synergistic Processing Elements (SPEs), and a Memory
Transfer Engine (MTE). This processor is embedded into Sony Playstation 3 [5].
This thesis uses Intel® i5 core as the computing platform and exploits multi-core
capability under .NET Framework 4 [4]. The i5 core has been specially designed as a parallel
computing platform for PC market. Parallel processing schemes, program partitioning and
optimization approaches will be elaborated in Chapter 5.
1.2 Research Approach
This thesis proposes a Genetic Algorithm (GA) based Multiple Model Reference
Adaptive Control (MMRAC) algorithm for F-16 flight surface control system. The system is
first simulated using built-in function free or numerical methods approach in MATLAB.
The developed control system is transformed into C++ under .Net Framework 4 based
system for embedded processing. Parallel processing techniques are applied to the control
system. Different designs are developed and compared with each other in order to optimize
the execution time of the control system. Different parallel processing techniques are
applied to the C++ control system program in order to maximize its overall speedup. The
optimal goal is to design the most accurate and a fast control system.
1.3 Organization
In Chapter 2, adaptive control algorithm and MRAC algorithm will be introduced and
the specific controller for flight surface control will be developed along with the stability
4
analysis. Chapter 3 will focus on the flight model design and MATLAB simulation results.
The aircraft model will be divided into different building blocks for the ease of
understanding and simulation. The focus is to get an accurate control for pitch, roll and yaw
position tracking. Chapter 4 will develop a Genetic Algorithm (GA) based Multiple Model
MRAC control (MMRAC) algorithm. The simulation results will be provided and will be
compared with those obtained from the previous control scheme. In Chapter 5, parallel
processing techniques will be applied onto the C++ program. Several optimization
approaches will be used to improve its computational performance. The execution times will
be optimized and will be used to assess performance of the proposed control system.
5
Chapter 2
Model Reference Adaptive Control

(MRAC)
2.1 Introduction to Adaptive Control
The adaptive control was first introduced from the extensive researches of aircrafts‟ auto
piloting issues in the early 1950s [1]. It was found that systems such as aircrafts operate over
various altitudes, speeds, aerodynamics, gravity and other conditions. Therefore, command
feedback control algorithms which only work for one operating condition would no longer
fit the new situation. While, the word “adapt” in adaptive control means “to conform one to
new or different conditions”. Accordingly, an adaptive controller is able to modify its control
scheme in accordance to the new circumstances, not simply one operating condition [2].
On the other hand, with the development of system identification, stability theory,
coefficient estimation and stochastic control theory in 1960s, adaptive control algorithms
became implementable theoretically. In the early 1980s, extensive research was conducted in
this area and adaptive control became a field of study. Adaptive control can be used for
practical applications. Adaptive control algorithm based control systems can be implemented
using modern computing technology [3] [6].
6
2.2 Definitions and Concepts
Most adaptive controllers perform the control process in two ways. One of them is to
make changes to the controller itself (gains); the other is to change the system parameters
(damping) in response to changes in operating conditions. As such, they can be simply
viewed as just another kind of control-law, only in a non-linear and complex way [7].
The common definition assumes that controller parameters are selected by the
adaptation process. The adaptation is associated with the information „learned‟ by the
adaptive controller. Following are mathematical definitions that are used in this work [8].
1. Adaptive means „to conform one to new or different conditions‟ [1].
2. An Adaptive System is one that measures its performance relative to a given index
of performance and modifies its parameters to approach an optimum set of values
(Eveleigh, 1967) [2].
3. Adaptation is the ability of self-adjustment or self-modification in accordance with
changing conditions of environment or structure (Aseltime et al., 1958) [3].
4. A system A is adaptive with respect to a family { }, of input sets =
{ }, where each is a vector of inputs to A. If the performance function
obtained when is applied to A is acceptable, i.e. belongs to the set W of
acceptable performance function values then A is adaptive with respect to G and W.
A maps G into W adaptively [7].
Thus a process/controller system is adaptive with respect to a specified set of
environmental changes, external disturbances, etc., if its performance function is
acceptable for all such changes.
7
Without defining adaptive directly, Tsypkin (1971) described some characteristic features
of adaptation [7].
The most characteristic feature of adaptation is an accumulation and a slow usage of
the current information to eliminate the uncertainty due to insufficient a priori information
and for the purpose of optimizing a certain selected performance index.
An input to a partially known system has the dual effect;
1. It will drag the output to move toward a desired value;
2. It will lead the output to change in a manner that will allow some of the unknown
parameters of the system to be determined [8].
2.3 Examples of Adaptive Controller
Generally speaking, adaptive control theory offers a balance of many aspects of control
theory including stability, parameter estimation and control law design. There are lots of
different adaptive control schemes available in the literature [9] [10]. A few adaptive
approaches would be discussed next.
Gain Scheduling is a possibility when one group of system parameters is not enough
for the whole operating conditions. It is literally open-loop and actually one step removed
from having gains selected from tables by human operators. Data is sensed to determine an
operating region from a lookup table and operating region is defined as a part of the entire
state space [1].
Self-tuning Regulators is an adaptive approach in which the system is identified and
the system information is used to design various parameters of a controller. It is a close-loop
control process and during each loop, system and controller parameters are determined
using the system identification process [2].
8
Model Reference Adaptive Control (MRAC) is characterized mainly by the pre-
defined system model. The controller parameters are adjusted towards the model so that the
system would finally behave as the model. There are also many variants of Model Reference
Adaptive Control such as direct MRAC and indirect MRAC etc. One commonly used variant
of direct MRAC is to introduce several models at the same time in accordance with complex
operating conditions [11].
In this thesis, the focus is to control an F-16 flight surface system. The system is highly
non-linear in nature and the operating conditions are changing from time to time. Due to the
nature of flight system, a Multiple-Model MRAC controller is designed and embedded into
the flight system to control the aircraft surface. In the next section, MRAC theory will be
introduced and the stability analysis would be provided.
2.4 Model Reference Adaptive Control (MRAC)
Model Reference Adaptive Control introduces a reference model which describes the
desired performance of the controlled plant. The basic structure of a direct MRAC
controlled system is illustrated in Figure 2.1 [9].
Without the reference model, the entire system would be nothing but an ordinary
feedback control system. Error e is the difference between the plant output and the model
output. The adjust mechanism has all parameters that are going to be changed according to
the error e. Thus, two loops, the ordinary feedback loop and the adjust mechanism loop
could be treated as inner loop and outer loop, respectively.
9
Adjustment
Model
Mechanism
Uc
Controller Plant
Figure 2.1: Block diagram of basic MRAC controlled system
There are basically three approaches of designing a Model Reference Adaptive system,
the gradient approach, the Lyapunov functions and the Passivity theory [2]. The gradient
approach assumes that parameters change more slowly than other coefficients in the system.
This is important for the computation of the sensitivity derivatives which is an essential part
of the adaptation mechanism. Both the Lyapunov‟s stability theory and passivity theory have
been used to change the adaptation mechanism. This work will focus on using gradient
method (MIT rules) to design a MRAC controller.
2.4.1 Model-following
The model reference adaptive method provides a general method for adjusting the
parameters so that the close-loop transfer function will be close to a pre-defined model. This
kind of problem is called model-following [6].
Model-following is an efficient way of solving servo control problems as the basic idea is
simple and useful. A specified or predefined model, linear or non-linear, would be given to
achieve the desired response. The parameters in the system would be adjusted in order to get
output of the plant as close as possible to output of the model for given input
signals. Although perfect model-following could be obtained only in ideal situations, analysis
of it gives insight into the design problem.
Consider a Single Input Single Output (SISO) system as shown in Figure 2.2.
10
Regulator Process
u y
T Sy
Figure 2.2: A SISO system with a general regulator
The transfer function of the system in Figure 2.2 is expressed as:
(2.1)
In which u is the control signal and y is the output signal. A and B represent polynomials
and use differential or difference equations.
If a regulator needs to be identified then the relation between the command signal
and the desired output signal is given by
(2.2)
In which and are again polynomials and contains differential or difference
equations. A general linear control law is described as:
(2.3)
where R, S and T are polynomials. Equation 2.3 represents a negative feedback with the
transfer operator – and a feedforward with the transfer operator . Elimination of
in Equations 2.1 and 2.3 results in the following equation for the closed-loop system:
(2.4)
must divide in order to obtain the desired response [6].
11
2.4.2 MIT rule
The basic idea in adjusting controller parameters in MRAC is commonly known as the
gradient approach. The gradient approach was first developed at the MIT‟s Instrumentation
Laboratory. Thus, the gradient method of MRAC is often called the MIT rule [1].
Controller parameters of the regulator are changed in the direction that brings the
difference between the process output and the model output to zero. A cost function is used
as description of the controller parameter in terms of the error e. The cost function of the
controller parameter is changed in such a way as to reduce the error. Controller parameters
are denoted by . A common cost function is given as:
(2.5)
In order to tune towards zero, J should be minimized by changing the parameter in
the direction of the negative gradient of J, for example,
(2.6)
The derivative is the sensitivity derivative of the system. The adjustment rule of
Equation 2.6 is referred as the MIT rule.
Equation 2.6 also applies to the case of a vector of adjustable parameters. In that case,
should be a vector and the sensitivity derivative should be the gradient of the error
with respect to the controller parameters.
The MIT rule performs well when the adaptation gain is small. The size of is
dependent on the value of the reference signal and the gain of the system. Moreover, the
convergence rate depends critically on Therefore there is no fixed limits that the control
process would be stable. This is why we also have the normalized MIT rule.
12
2.4.3 Normalized MIT rule
As MIT rule does not guarantee stability, it is imperative for people to modify it. As
mentioned above, MIT rule let the users decide the critical parameter , which determines
the rate of decrease of the cost function [7]. Thus it is possible to obtain a modified rule in
which the rate of decrease would not depend on , nor the value of the command signal.
One successful way is to normalize and replace the MIT rule with
The existence of the parameter is introduced in case of division by zero. A saturation
parameter is introduced to avoid any calculation error and to keep the adjustment rate below
a certain limit. Thus the adjustment rule is changed as:
in which,
(2.9)
Equation 2.8 is called the normalized MIT rule which makes the adjustment rate
not totally dependent on . With the introduction of the parameter , a predefined limit is
set to avoid the rate of decrease from becoming too large. Thus the stability of MRAC
algorithm is guaranteed [7].
13
2.4.4 A MRAC Example
In order to make a clear view of the Model Reference Adaptive Control, a system with a
forward gain (k) will be given as an example. Figure 2.3 shows the block diagram of a
forward gain system with MRAC as an embedded controller [10].
Figure 2.3: Block diagram of a MRAC embedded system
From the diagram, the transfer function of the plant is obviously
(2.10)
In which k is an unknown parameter, but a could be introduced in the model and let
the system keep moving closer towards the model through the adaptation process. Therefore,
the model is defined by the transfer function of the plant with multiplication by a new
constant .
(2.11)
A similar cost function is selected as given in Equation 2.5, which gives the adaptation
result as specified by Equation 2.6. In terms of the transfer function of this particular system,
the error equals to
(2.12)
14
where θ is the controller parameter that needs to be adjusted as it is affecting error e. In
terms of the system output, the sensitivity derivative is expressed by:
(2.13)
At the last step, MIT rule is applied and the mechanism to adjust θ is determined.
(2.14)
Equation 2.14 is used to tune the system towards the model and it will result in getting
closer to [10].
Adaptive control is useful for complex and highly non-linear systems. MRAC system is
one of the most common algorithms in the area of adaptive control. Due to the nature of F-
16 flight surface control system, MRAC is selected to adjust the system parameters according
to a preset model or a series of models. In the next chapter, the F-16 aircraft model will be
illustrated and the specific MRAC control law will be developed in regards to the flight
model.
15
Chapter 3
F-16 Flight Surface Control Model
3.1 F-16 Flight Model
Model Reference Adaptive Control (MRAC) algorithm has been proven to be accurate in
response, fast in convergence and stable during control process. It is also very appropriate
for use in a highly non-linear system. Flight control models generally are highly complex in
nature and the deviation of flight surface changes the aerodynamic forces and moments
which are also highly non-linear [12]. In addition, the rapidly changing temperature and air
pressure influences the speed and altitude.
Stevens and Lewis [14] have described F-16 aircraft flight model in their book “Aircraft
Control and Simulation”. The F-16 aircraft flight model is provided in great details and
various associated program codes with various look up tables are also available. Kamalasadan
and Ghandakly have provided a neural network and fuzzy logic based MRAC system for this
F-16 aircraft model [13]. Therefore choice of MRAC in this work is very appropriate to
perform flight surface control system [13].
An aircraft has three axis namely longitudinal, vertical and lateral. There are also three
parameters roll, yaw and pitch that affect the rotation of a flight in the air. These three
rotations are controlled by surfaces including ailerons, rudders and elevators. Three rotations
16
of an aircraft are shown in Figure 3.1 (Figure obtained from NASA). A detailed diagram of
an aircraft with its various surface control system is shown in Figure 3.2 (Figure obtained
from NASA).
Figure 3.1: Aircraft 3-axis rotation (NASA) [15]
There are three motions along three axes (longitudinal, lateral and vertical) of an aircraft:
front and back along the longitudinal axis; side to side along the lateral axis; up and down
along the vertical axis. Besides, there are three rotations around these axes: pitch (movement
around lateral axis), roll (movement around longitudinal axis) and yaw (movement around
vertical axis). Pitch rotations make an aircraft move upward or downward; roll rotations
make an aircraft roll along longitudinal axis (roll around its body); yaw rotations make an
aircraft turn right or left. Since the aircraft has three rotations and three motions, therefore
an aircraft system is called 6-DOF (Degree Of Freedom) system.
17
Figure 3.2: Surfaces on an airplane (NASA) [16].
As Figure 3.2 shows, the ailerons are located on the trailing edge of wings, near the wing
tip of an airplane. They can be used to generate roll rotations. Ailerons are used in opposite
directions which means that when left ailerons deflect upward, the ones on the right have to
move downward. For example, when the left ailerons tilt up and right ailerons tilt down,
more lift is created on the left side and less on the right side. This would result in the aircraft
rolling to the right.
Elevators are located at the trailing edge of the horizontal stabilizer. They control the
pitch motion, which means that the plane lifts its nose up and down. When elevators are
deflected downward, more lift will be accumulated at the horizontal stabilizers and the
aircraft will move downward. In order that the planes fly horizontally, the total sum of pitch
moments must be zero [16]. Thus altitude changing requires the elevators‟ momentary going
down after going up in order to keep the flight parallel to the ground. On the other hand, as
these elevators are parallel to ailerons, they also have effects on roll controls [17].
Rudders are located at the trailing edge of the vertical stabilizer which control yaw
motions [18]. Rudders are extended so that they obstruct the airflow [19]. In turn, the airflow
18
will push hard on the rudders. Unbalance will be created between the side where the rudders
are obstructing the airflow and the side where they are not. Aircrafts will finally move away
from the side where rudders are extended. Therefore, when rudders tilt to the right, more lift
is created on the right, which will push the vertical stabilizer to the left. This will cause the
airplane to yaw to the right [20].
Table 3.1 lists the relation between three rotation motions and surfaces.
Table 3.1: Relationship between Roll, Yaw, Pitch and Aileron, Elevator and Rudder
Rotation
Surfaces that affect
motions
Deflection of conventional wing-mounted ailerons and differential
Roll
deflection of the horizontal stabilizers
Pitch Elevators deflection
Yaw Rudder deflection
The specifications and control of all three rotations systems will be presented later in this
thesis.
3.2 Mathematical Model of F-16 Aircraft
A mathematical model for the six degree of freedom for the F-16 aircraft has been
developed by NASA-Langley and is also given by Steven and Lewis [14]. A mathematical F-
16 flight model is provided in terms of body dynamics, aerodynamics and force equations
[21]. The steady state trim [22] conditions will be developed thereafter.
The mathematical model developed from the data obtained from NASA-Langley wind
tunnel test applies to a speed range up to Mach number=0.6 [14]. The Mach number
describes the speed of the aircraft. The model confines limits to various actuators including
leading edge flap deflection, horizontal stabilizer, differential tail, aileron and rudder. These
limits are listed in Table 3.2.
19
Table 3.2: Degree limits of various deflections and actuators
Actuator Degree of limit(deg)
Leading edge flap deflection 0°to 25°
Horizontal stabilizer -25°to 25°
Differential tail -5.38°to 5.38°
Aileron -21.5°to 21.5°
Rudder -30°to 30°
The aircraft model is based on force, kinematics, moment and navigation equations.
These equations are also available in [13, 14].
Force equations are represented as:
(3.1)
(3.2)
(3.3)
Kinematic equations are represented as:
(3.4)
(3.5)
(3.6)
Moment equations are represented as:
(3.7)
(3.8)
(3.9)
Navigation equations are represented as:
20
(3.10)
(3.11)
(3.12)
The total control input vector could be written as
(3.13)
Equations from 3.1 to 3.13 are system equations which provide the back bone of the
entire surface control. Various parameters used in this model are shown in Table 3.3.
Table 3.3: Model parameters
Parameters name Practical meaning
U Velocity along longitudinal axis (km/s)
V Velocity along lateral axis (km/s)
W Velocity along vertical axis (km/s)
P Roll rate (rad/s)
Q Pitch rate (rad/s)
R Yaw rate (rad/s)
Force along longitudinal axis (N)
Force along lateral axis (N)
Force along vertical axis (N)
Euler angle along longitudinal axis (rad)
Euler angle along lateral axis (rad)
Euler angle along vertical axis (rad)
21
Mathematical equations of the F-16 aircraft model are supported by look up tables. They
provide basis of the aircraft flight surface control. These look up tables provide coefficients
for equations of motions according to different flying conditions. They are obtained from
the steady state flight trim conditions and corresponding dynamic conditions [13].
3.2.1 MRAC controller of F-16 Aircraft
This thesis is focused on surface control of the F-16 aircraft. This work is concerned
with the pitch, roll and yaw control. These controls can be described as:
Pitch rotation is determined solely by deflection of elevators. Therefore it can be
controlled by following equations.
(3.14)
Where represents gain on elevators and is expressed as follows:
(3.15)
Both and are four-element 1-D arrays. is composed of accumulated
changes of . is expressed as an array and is given as:
(3.16)
Where is the desired pitch rate value and is the current pitch rate value
whose unit is .
Similar to pitch control process, yaw rotation is influenced only by rudder. Yaw control
can be described as:
(3.17)
Where is the gain on rudder and has been shown in Equation 3.15. The only
difference is that in this case is expressed as:
22
(3.18)
where is the desired yaw rate value and is the current yaw rate value.
Roll rate control process is slightly different from the previous two rotations (pitch and
yaw) and is determined by both ailerons and horizontal stabilizers. Therefore, roll control
can be described as:
(3.19)
At the same time, elevators need to change its value in the following way:
(3.20)
The parameter in both Equation 3.19 and Equation 3.20 equals to
which is the same as pitch and yaw rotations. The difference lies in that and is stated as:
(3.21)
The MRAC controller parameters in Equations 3.14 to 3.21 are summarized in Table 3.4.
Table 3.4: Controller parameters
Parameter name Practical meaning
Pitch rate (rad/s)
Yaw rate (rad/s)
Roll rate (rad/s)
Gain on elevators (rad)
Gain on rudders (rad)
Gain on ailerons (rad)
Accumulated change of (rad)
Current Pitch, Yaw, Roll rate (rad/s)
Desired Pitch, Yaw, Roll rate (rad/s)
23
3.2.2 Structure of F-16 Aircraft Body and MRAC Control system
Figure 3.3 describes computational model of the F-16 Aircraft flight surface control
system. It shows main computational blocks inside the object body and it is surrounded by
other computational sub-blocks. Figure 3.3 also shows various inputs going to different
computational sub-blocks.
Computation of Computation of
Mach number aerodynamic forces
and dynamic and moments
pressure coefficients
Altitude Surface
Velocity angles
Object Body
1 Values of Ailerons, Rudders,
Elevators and Flaps.
2 Description of engine model.
3 Calculation of atmosphere density,
dynamic pressure and navigation
equations.
4 MRAC Controller.
Throttle angle, Angle of

altitude, Mach number attack
Computation Add damping

of engine thrust derivatives
Figure 3.3: F-16 aircraft body system architecture
Computation of the entire model is encapsulated in Figure 3.4. It is divided into three
major blocks of input parameters, computational block and output values. Figure 3.3 serves
as a plant and is shown as one of two computational blocks in Figure 3.4.
24
Input Block
Velocity (U,V,W), Altitude,
Mach number, Moment rates
(P,Q,R), Kinematics ( )
Computational Plant
Force Equations: Equations 3.1 to 3.3
Kinematic Equations: Equations 3.4 to 3.6
Moment Equations: Equations 3.7 to 3.9
Navigation Equations: Equations 3.10 to 3.12
Computational Controller
Rotation Control Process (Controller)
Pitch Rotation Control (3.14 to 3.16)
Yaw Rotation Control: (3.15, 3.17 and 3.18)
Roll Rotation Control: (3.19 to 3.21)
Output Block
Pitch, Yaw or Roll Rates
( )
Figure 3.4: Computational flow of flight surface control
3.3 Simulation Architecture
Model Reference Adaptive Controller (MRAC) based surface flight control model has
been presented in previous sections. In order to validate correctness of the model and the
control system, it should be simulated first. Kamalsadan in his Ph. D. dissertation provides
MATLAB code for pitch control using MRAC approach. This thesis takes his work one step
further and first simulates three rotation controls (pitch, roll and yaw) for flight surface
control system. One of the stated goals of this thesis is to develop an embedded flight
control system exploiting parallel processing and utilize available modern Multi-Core system
to achieve real time embedded flight surface control system.
25
3.3.1 Simulation Model Building Blocks
The F-16 6-DOF aircraft model and its associate MRAC based surface flight control
system consist of two main computational blocks of plant and controller as shown in Figure
3.4. The computational blocks also rely upon computation of sub-blocks such as engine
thrust and power command, aerodynamics, atmosphere block, Mach number, dynamic
pressure and damping derivatives. Main computational blocks and sub-computational blocks
heavily rely on the concept of look up tables for various coefficients. It should also be noted
that all control systems involve computation of partial differential equation in the form of
(3.22)
This equation tunes towards zero and requires minimization of J by varying the parameter
in the direction of the negative gradient of J.
The MRAC system is adjusting parameter θ and error e between system output and
model output. The surface flight control system involves control of three rotations and
following sections describe various initial conditions.
3.3.2 MATLAB Flight Model
The computational flow of aircraft surface control system has been developed in Figure
3.4. The aircraft surface system and MRAC controller blocks have been designed as shown
in Figure 3.5. Since MATLAB focuses only on digital systems, the continuous models have
to be transferred into its discrete counterpart.
During discretization, the entire process is distributed on a time line. The time parameter
is represented by T and is used as 180. A step size or sampling rate h is used. The total
number of samples equals to T/h.
26
Start
Input Block
Command Signal
(RCOM,QCOM,PCOM)
Surface angles (Elevator,
Aileron, Rudder)
Velocity (U,V,W)
Moment rates (P,Q,R)
kinematics ( )
Aerodynamics (F1-F3)
Aerodynamics (F4-F10)
Computational Block
18689
iteration Force Equations: , ,
s Kinematic Equations:
Moment Equations:
Navigation Equations:
Engine (F11-F13)
Damping (F14)
MRAC Controller
Pitch Rotation Control
Yaw Rotation Control
Roll Rotation Control
Discretization
Process
Output
Figure 3.5: Simulation flow chart of MRAC based F-16 surface control system
27
Functions from F1 to F14 in „Input Block‟ and „Computational Block‟ are computational
functions that calculate various parameters. Physical meanings of these functions are shown
in Table 3.5.
Table 3.5: Physical meanings of computational functions
Function Number Physical meaning
F1 to F3 Aerodynamics around three axes
F4 to F7 Aerodynamics on ailerons, rudders, elevators and flaps
F8 to F10 Aerodynamics along three axes
F11 to F13 Engine power and thrust
F14 Damping derivatives
It can be seen that flight surface control system utilizes input signals to compute
movement parameters such as forces, kinematics, moments and navigation values of aircrafts
and these parameters are transferred to the MRAC controller as inputs. Controller block
calculates how much surface angles (Elevators, Ailerons and Rudders) need to be adjusted
and return the adjustments back to the input block as a completion of one discretization
step.
The tracking results ( ) will be shown in terms of matrix or figures. In
this thesis, the final surface tracking results will be graphically displayed. Figures will have the
x-axis as the time line T and y-axis will be the rotation changing rates ( ).
3.3.3 Initial State of Pitch Rotation System
The MRAC system adjusts the degree of deflection of elevators. Besides elevators, other
surfaces also play important roles in pitch rotations since they are able to balance the other
28
two axes of the aircraft system. The pitch angle is mainly determined by elevators. In
rotation control systems, all surfaces need to have initial values and these values keep the
aircraft fly smoothly if no external command were given. The initial state of the aircraft is
given in Table 3.6. These data are given by Stevens and Lewis [14].
Table 3.6: Initial State and Command Signals for pitch position tracking control
Elevator (degree) Aileron (degree) Rudder (degree)
-0.7588
Initial surface angles during steady state
Time (second) <10 <20 <40 <100 <150
Pitch Rate (Degree/sec) 0 8.5 0 10 3
Throttle Value (Degree) 0.1385 1 0.7 0.5 0.95
Aileron (Degree)
Rudder (Degree)
Control vector and command values
3.3.4 Initial State of Roll Rotation System
Roll position control is similar to the pitch control. The MRAC updates the angles of
both ailerons and horizontal stabilizers. The initial state and command pattern of roll control
are listed in Table 3.7. It shows that the initial values of surfaces and throttle angles remain
the same as pitch control but it will have different command signal. Command values for
three rotations are specified in random fashion for simulation purposes.
29
Table 3.7: Initial State and Command Signals for roll position tracking control
-0.7588
Throttle Value in the control process
Time(second) <10 <20 <40 <100 <150
Pitch Rate(Degree/sec) 0 2 5 3 1
Throttle Value(Degree) 0.1385 1 0.7 0.5 0.95
Aileron(Degree)
Rudder(Degree)
Control vector and command values
3.3.5 Initial State of Yaw Rotation System
The MRAC system adjusts rudder angle for the yaw rotation. Its initial state and control
pattern is given in Table 3.8. The yaw rotation will have different command signal as
previously suggested.
30
Table 3.8: Initial State and Command Signals for yaw position tracking control
-0.7588
Throttle Value in the control process
Time(second) <10 <20 <80 <150
Yaw Rate(Degree/sec) 0 1 2 1
Throttle Value(Degree) 0.1385 0 0 0
Aileron(Degree)
Rudder(Degree)
Control Vector and command signal
3.4 MRAC based F-16 Flight Surface Control Simulation
3.4.1 Pitch Rate Control
The MATLAB simulation for pitch rate control similar to Kamalasadan [13] is shown in
Figure 3.6.
31
Figure 3.6: Pitch Rate control result using „ODE45‟
One of the advantages of MATLAB is that it provides built-in functions for many
modern computational needs with the availability of its various tool boxes. One can quickly
simulate a fairly complex system using MATLAB and its associated tool boxes. If special
purpose hardware needs to be designed for real time applications which will require either
C/C++ code or low level implementation then one of the task would be to replace all
existing built-in functions in the MATLAB code. The existing code has similar situation and
utilizes built-in Runge-Kutta function „ODE45‟. Efforts were directed to replace „ODE45‟
with custom code and duplicate existing results. This effort of replacing „ODE45‟ which is a
Runge-Kutta function for the solution of partial differential equation is described in the next
section.
3.4.2 Runge-Kutta 4th Order Method
Runge-Kutta is a technique that solves differential equations and it was developed by
German mathematicians C. Runge and M. W. Kutta around 1900. Among the family of
32
Runge-Kutta, the 4th order method is the most commonly used in solving differential
equations. It could be represented as follows.
An initial value is specified as follows.
(3.23)
(3.24)
Then the Runge-Kutta method is given by the following equations.
(3.25)
(3.26)
(3.27)
(3.28)
Basically, Runge-Kutta changes the process of solving differential equations into iterative
computations. A step size h is chosen and a continuous problem is discretized.
Original MATLAB code was modified and the „ODE45‟ function was replaced with the
Runge-Kutta 4th order code. As expected, the output is almost similar to one with the
„ODE45‟ function and is shown in Figure 3.7.
In Figure 3.7, the result from „ODE45‟ is represented with red dot line and the result
from the new code is represented with blue solid line. The slight difference between the two
can only be seen on the up-edges when t=10 and t=40 and the down-edge when t=20. For
the rest of the position tracking process, these two different pieces of code performs exactly
the same. This is due to the fact that MATLAB‟s ODE45 function also uses Runge-Kutta
algorithm.
33
Figure 3.7: Comparison of pitch control with the function „ODE45‟ and the custom
code
The MRAC system performs pitch control and the error between the command pattern
and the tracking result is shown in Figure 3.8.
Figure 3.8: Error magnitude between the pitch control tracking and the command signal
It can be seen that the error is high only at the transition points and it quickly subsided
later on. Therefore it can be concluded that the MRAC system is achieving its goal.
34
3.4.3 Roll Control
The MRAC system was simulated using the custom Runge-Kutta code for the roll
control and its result is shown in Figure 3.9.
Figure 3.9: Roll rate control result in comparison with the command pattern
The roll position tracking performs as well as the pitch rate control although the system
converges a little bit slow when „Roll Rate=2‟. The rest of the process gives quick response
and provides accurate results. The error was also plotted and is shown in Figure 3.10. It can
again be seen that there is large error only at the transition points.
35
Figure 3.10: Error magnitude between the roll control tracking and the command signal
3.4.4 Yaw Control
The yaw control tracking with the MRAC is shown in Figure 3.11. In Figure 3.11, the
solid blue line represents the tracking result of yaw control and the red dot line represents
the command signal. The yaw control track from the MRAC system deviates from the
command signal. It can be seen that the control system is converging slowly due to the MIT
based MRAC. The reason is that the deflection of rudder is not enough for yaw control and
requires larger rudder deflection.
36
Figure 3.11: Yaw rate control result in comparison with the command pattern
According to video demonstrations [17] available on Youtube, when an aircraft makes a
yaw rotation, a roll rotation is always accompanied. This failure of convergence could be
diminished by enhancing roll rotation control. Another option would be to utilize multiple-
model MRAC controller as discussed in the next chapter.
37
Chapter 4
Genetic Algorithm Based Multiple Model

MRAC
A MRAC system for three rotation motions of F-16 aircraft was presented in Chapter 3.
The MRAC system is considered as a single-model system that may have some
disadvantages. The system relies only on one single model and tries to perform as best as it
can. It was observed that both the pitch and roll control system response quickly and
accurately under a predefined model over the entire control process. Unfortunately, yaw
control process results in a non-stable system. Its system response fails to converge on the
command signal. To overcome this issue, on one hand a new control scheme could be
designed which holds better stability; on the other hand, a better model or multiple models
within the framework of MRAC [12] can be employed. In this thesis, the idea of number of
models within the framework of MRAC is pursued. An intelligent approach may be
employed to select the best model for a given situation [23].
This chapter presents the development of a Multiple-Model MRAC (MMRAC)
controller and series of models which represent different flight conditions will be generated.
Genetic Algorithm (GA) technique as an intelligent mechanism will be used to generate and
select models to make safe switching decisions. For every control command value, a best
model will be selected by a properly developed fitness law [24].
38
4.1 Multiple-Model MRAC (MMRAC)
4.1.1 The need for MMRAC
A single predefined model was used in the previous chapter for the MRAC for the flight
surface control system. The simulation result shows that both pitch and roll control result
satisfy tracking trajectories in reasonable time. The problem arises from yaw control which
results in slow convergence rate. That is to say, given the same processing time as pitch and
roll control, single-model MRAC for yaw control makes it unstable.
Figure 4.1: Yaw control result under a new command signal
A test command signal for the demonstration of yaw control is designed and is provided
in Table 4.1.
Table 4.1: Yaw Rate and Throttle Command Value
Time(sec) <10 <20 <80 <150 <180
Yaw Rate(Deg) 0 1 1 1 1
Throttle Value(Deg) 0.1385 0 0 0 0.1385
39
Figure 4.1 shows that the single-model MRAC controller designed for yaw motion
control is stable but it takes long response time to stabilize.
The yaw control command only changes once and gives the system long tracking time
(from t=10 to t=180) and allows monitoring of its stabilization time. Figure 4.1 shows that
the system converges at t=35, which proves that the controller is stable for the yaw control
system but just taking long time to converge. The reason why it takes long response time to
converge is that the predefined model for the system is not able to provide desired result.
Therefore, the initial error between the model and system is too much to be offset in a short
response time.
A Multiple-Model MRAC [24] may solve this problem since the initial difference
between system output and model output can be minimized by selecting the best model
from a pre-generated model pool [27]. Next two sections will introduce MMRAC structure
and safe switching scheme.
4.1.2 Multiple-Model Reference Adaptive Control
It is assumed that for multiple-model reference adaptive control, the unknown system is
represented by series of nominal plants or at least one member of them. Each nominal plant
corresponds to a presumed stable controller which gives the unknown system a satisfactory
performance. The overall objective of MMRAC is to converge to the best controller for the
unknown system after a finite time [27].
For some of the cases, the determination of the best controller is definite. But for others,
this determination falls into an uncertainty zone. For example, given the nominal system ,
there is a hypothesis that makes the unknown system falls into the uncertainty zone
around . It is the supervisor‟s job to determine the best and select the best
40
corresponding controller. Figure 4.2 shows the structure of a MMRAC system without any
system disturbances [28].
Model
Selection
System
U System
Estimation
Figure 4.2: Structure of MMRAC
There are m nominal systems from to . Each of the nominal systems corresponds
to a Controller . Each output corresponds to a nominal system and y
corresponds to the output of the unknown system. The difference between the outputs of
the unknown system S and m system model is . The model selection block computes
various performance parameters and selects an appropriate model which is closest to the
unknown system . It determines a suitable based on the information of
4.1.3 Model switching
The model selection system in Figure 4.2 relies on a concept of monitoring signals which
are defined by the following equation.
(4.1)
This monitoring signal gives a measurement of the closeness between the unknown
system and possible models [27]. It should also be emphasized that the choice of
is based on the satisfaction of the performance for the model .
41
The model selection system does not wait for the monitoring signal to converge to zero.
That is to say, if the unknown system S is time-varying, the controller may never settle down
on a specific . The model selection system considers unknown time-varying
system as number of time invariant systems. Only in this way, at a specific time t, a nominal
model could be selected and a corresponding controller will in fact control the system.
Multiple-Model Reference Adaptive Control system is capable of providing superior
performance than a single model based approach [28]. Therefore a MMRAC has two basic
building blocks. One of them contains multiple models of the system. The second one
which is a model selection system contains an intelligent scheme to properly select an
appropriate model for certain conditions and based on certain performance parameters. It is
easy to provide multiple models but development of model selection system can be a
challenging task [31]. There are number of intelligent techniques that can be used to develop
and adopt a model selection system. These intelligent techniques can be based on fuzzy
logic, neural network, or genetic algorithm and others [33]. Researchers have used fuzzy
logic and neural network based approaches extensively in the past. More recently there is lot
of interest in use of genetic algorithms [35]. Obviously there are tradeoffs in the use of all
these approaches. Selecting one can be challenging as it would require extensive simulation
and performance evaluation. In this thesis, genetic algorithm based model selection system
has been proposed.
4.2 Genetic Algorithm (GA)
4.2.1 Basics of GA
Genetic Algorithm (GA) is a computational model that came from the natural evolution
back in the 1970‟s [35]. The implementation of GA begins with a population of

42
chromosomes which represents specific variables of a problem. Then the individuals that
keep the population better evolving are assigned with greater possibility of reproduction and
those who fail in the natural selection would finally be ruled out [36]. The evaluation scheme
of chromosomes is called fitness functions, which is defined by the designer. A one-time
reproduction is illustrated in Figure 4.3 [35].
Figure 4.3: An example of one-time reproduction
In Figure 4.3, both solid and diagonally hatched block represent genes. GA presumes
that the solution to a problem is an individual that could be represented by a set of
parameters. These parameters are in turn the genes of the chromosomes and represented by
an array of binary digits [37]. The initial genes of a chromosome are usually randomly picked.
With the evaluation of the fitness function, better genes are retained and losers from the
competition get deleted from the population.
The size of the initial population varies from problem to problem [35]. In every
reproduction step, the next generation is created from the current generation. The genes of
the parent generation will be mixed and combined into the ones of their offspring as shown
in Figure 4.3. For a well-designed GA process, better genes should take larger number of
places in the offspring [38]. A commonly used technique for selecting the best individual
chromosome is called roulette wheel selection. It is described by following three steps [39]:
1. Calculate the sum of the fitness of every individuals of the parent generation, as S;
2. Randomly generate a number between 0 and S, namely n;
3. Return the first individual whose fitness value added to S is greater or equal to n.
43
There are two techniques for terminating GA process. The first one is that the designer
presets a cycle number and the reproduction process stop when this number is reached. The
best individual is returned according to the fitness value. The other method is that the
designer presets a termination fitness value. When there is an individual who reaches the
criterion, the entire process stops [36].
There are two fundamental operators that facilitate the evolution cycles, crossover and
mutation [35]. Figure 4.3 could be viewed as a one-time crossover. After each crossover,
every individual is applied with mutation from which genes could be altered. They could be
changed to other genes in the population or new genes that never exist could be introduced
into the pool. The mutation is applied under a relatively small possibility in order to keep the
evolution towards a fixed direction. For example, one of the solid blue genes on the parent
side of Figure 4.3 has the possibility of 0.01 that could be altered to a black-dot one as
illustrated in Figure 4.4.
Figure 4.4: An example of mutation under probability of 0.01
A desired fitness value of 30 and 100 cycles of reproduction have been selected to
illustrate operation of GA algorithm. The chromosomes are represented by binary digits and
the fitness values are listed following the chromosomes as shown in Table 4.2. There are
four individuals in the first generation and their fitness values are provided in Table 4.2.
44
Table 4.2: Parent selection
First Generation Fitness Value
1100110110101000 3.481746
0101010110110101 3.668023
1000010100110110 6.261380
1101011111001100 12.864222
During the parent selection, the lower two individuals are selected as they hold the
greater fitness value than the first two individuals [35]. It should also be noted that the
fitness value can be selected either greater or lower and it determines the direction of
reproduction. The crossover point is selected to be after the fifth digit of every
chromosome. The crossover process is shown in Figure 4.5.
11010 11111001100 11010 10100110110
10000 10100110110 10000 11111001100
Figure 4.5: The crossover step
These two chromosomes interchange with each other their first 5 digits and last 11
digits. Mutation process changes binary digits with a predefined probability. Mutation offers
a possibility of improving genes. Therefore after each crossover there is a possibility of
mutation as shown in Figure 4.6.
45
1101011111001100 1000010100110110
1111010100100110 1010011011001100
Fitness value=8.044649 Fitness value=6.092550
Figure 4.6: The mutation step
Next, these two new individuals will be inserted into the population and a new
generation will be created as shown in Table 4.3.
Table 4.3: A new generation
First Generation Fitness Value
1111010100100110 8.044649
1010011011001100 3.668023
1000010100110110 6.261380
1101011111001100 12.864222
At last, after 100 cycles of reproduction, the best chromosome which holds the fitness
value 29.000320 is returned. The binary number then is decoded back into a decimal one as
the final result [40].
4.2.2 Why Genetic Algorithm
The mathematical representation of the trim condition F-16 aircraft model is given as:
(4.2)
It is a simple calculation in which and are two coefficients that both have their
own value domains; and are two parameters of MRAC adjuster. For every iteration
previously computed values of and are used. Two coefficients of and are
46
first selected randomly and then they are generated by the GA algorithm. Error is computed
by the following equation.
(4.3)
(4.4)
where is the angle of rudder, which is the parameter that needs to be adjusted and is
also fixed within every iteration. The best model is the one that produces the least error from
the system output and that particular model is selected for control purposes.
The simple approach of randomly picking coefficients first and obvious fitness law
makes genetic algorithm the best choice to select the best model for every command value.
4.3 GA based MMRAC
4.3.1 MMRAC mapping onto flight surface control
It is possible to design an F-16 flight surface control system with a genetic algorithm
acting as a model selection system. For the first step, a basic architecture should be designed
in order to have a clear view of the control process. A genetic algorithm based MMRAC
structure is shown in Figure 4.7.
47
Adaptive
Adjustment
Control Law Unknown

System
Models
GA model
generator
Figure 4.7: Block diagram of GA based MMRAC
The MMRAC system contains arrow-crossed block labeled as Models and this model
block will store multiple models. The other arrow-crossed block labeled as Control Law
computes values of changes needed in the system parameters. GA model generator will
evaluate these models according to a predefined fitness function. It will select an appropriate
model for the given command.
A general monitoring signal is previously defined by Equation 4.1. This equation can be
simplified for this flight surface control system as:
(4.5)
The surface flight control system needs to be viewed as a combination of set of time
invariant subsystems and the GA model generator acting as model selector. The command
signal is subdivided into sections which will have constant command values.
In this thesis, the system is separated into the same number of subsystems as the number
of different command values. For example, for the roll control system, if there are six
command values then a subsystem will be identified for each command value. A model will
be selected that will satisfy performance parameter for that particular command value. This
model will remain the same for the duration of specific command value.
48
4.3.2 GA mapping onto flight surface control system
The fitness function for the F-16 flight surface control system is defined by Equation
4.5. The candidate model output is used as and the system output is . In the
mathematical error model given in Section 4.3, the model output is determined by the
two parameters and . Both of these two parameters are limited to particular predefined
values in order to keep a stable controller.
(4.6)
These values are obtained from the MATLAB simulation experiments. Results show that
the system remains stable if these two parameters are within above limits.
Therefore, both and are converted into binary numbers and taken as two genes.
These two genes together form a complete chromosome. Every time the decimal value of a
particular chromosome exceeds the limit domain as given by Equation 4.6, it is deleted from
the population. The Table 4.4 describes the specific design of the GA model generator and
model selector for this aircraft flight surface control system.
Table 4.4: GA model generator
GA parameter name Value
Initial Population 20
Randomly generated Initial Population Within [0, 49]
Chromosome Length 32
Crossover Point The point after 16th digit
Fitness function
Mutation Possibility 2%
49
The next step is to apply the genetic algorithm to the MMRAC and embed the control
scheme into the flight surface control system. The entire process is simulated in MATLAB
to validate the GA based MMRAC system.
4.4 MMRAC Controlled flight surface control system simulation
Single model MRAC system was described and simulated in Chapter 3. It was noted that
only the yaw rotation control failed to perform within specified limits. Figure 4.8 shows
tracking of the yaw control command with the GA based MMRAC system.
Figure 4.8: GA based MMRAC yaw control
The error is plotted in Figure 4.9 based on single model MRAC and GA based MMRAC.
It can be seen that MMRAC was able to perform better than the single model MRAC.
50
Figure 4.9: Comparison between square-errors from normal MRAC and GA embedded
MRAC for yaw control
Figure 4.8 shows the command track in solid blue for GA based MMRAC and green
dash-dot line track belongs to the one with single model MRAC. It can be seen that the
MMRAC system converges very well from t=20 to t=80 and from t=150 to t=180. For the
region between (10 & 20) and (80 & 140), the system requires more convergence time in
order to obtain better control.
The Mean Square Errors (MSE) of tracking results generated by GA based MMRAC and
single model MRAC are shown in Table 4.5.
Table 4.5: Comparison of MSE for yaw control system
Controller MSE (rad/s)
GA based MMRAC 0.0138
Single model MRAC 0.0352
It can be seen that yaw rotation control system response generated by GA based
MMRAC has much smaller error than single model MRAC.
51
Pitch rotation control is plotted in Figure 4.10. It shows tracks from the command line
in red dash, single MRAC in green dash-dot and GA based MMRAC in solid blue. It can be
seen that MMRAC is still performing better than the one with single model MRAC.
Figure 4.10: MMRAC embedded pitch control result
The square error with respect to command, the single model MRAC and the GA based
MMRAC is shown in Figure 4.11.
Figure 4.11: Comparison between square-errors from single model MRAC and GA
based MMRAC for pitch control
52
It can be seen from Figure 4.11 that from t=40 to t=42, the trajectory generated by GA
based MMRAC which is represented by solid line drops much faster than the trajectory
generated by single model MRAC which is the dotted line. The MSEs of GA based
MMRAC and single model MRAC control systems are shown in Table 4.6.
Table 4.6: Comparison of MSE for pitch control system
It can be seen that system response generated by GA based MMRAC has much smaller
mean square error than single model MRAC.
The simulation result for MMRAC for roll motion control system is shown in Figure
4.12.
Figure 4.12: MMRAC embedded roll control result in comparison with command signal
The square error with respect to command, the single model MRAC and the GA based
MMRAC for pitch control is shown in Figure 4.13.
53
Figure 4.13: Comparison between square-errors from normal MRAC and GA based
MRAC for roll control
Figure 4.13 provides the comparison of square errors generated by GA based MMRAC
which is represented by solid line and single model MRAC which is represented by dotted
line. It can be seen that solid line drops much faster than the dotted line. Therefore system
response from GA based MMRAC has less error than the single model MRAC. The mean
square errors of both control schemes are shown in Table 4.7.
Table 4.7: Comparison of MSE for roll control system
It can be seen that GA based MMRAC results in slightly smaller MSE than single model
MRAC.
The MSEs generated by GA based MMRAC and single model MRAC for all three
rotation control systems namely yaw, pitch and roll are shown in Table 4.8.
54
Table 4.8: MSE comparison for three rotation control systems (rads/seconds)
Rotation control system
Control Scheme Yaw Pitch Roll
Single model MRAC 0.0352 0.0270 0.0081
GA based MMRAC 0.0138 0.0062 0.0091
For all three rotation control systems, GA based MMRAC controller controls the
position tracking more accurately and is more stable than the single model MRAC controller.
55
Chapter 5
Parallel Processing Using Multi-Core

The execution time of the MATLAB simulation program for MRAC and GA based
MMRAC for embedded F-16 flight surface control system takes from 300 to 330 seconds. It
means that for any change in command signal, the system has to wait around several seconds
for the system to stabilize. This time may be too large for a comfortable ride in the plane.
With the development of multi-thread computing technology and the availability of multi-
core CPUs and GPUs, improvement in terms of execution time is possible if these control
algorithms are implemented and mapped onto a multi-core architecture [41].
In order to take advantage of multi-core techniques, programming languages such as
C/C++ and other languages are necessary. The availability of multi-core processors from
Intel [42] in desktop or laptop computers and .NET Framework 4 from the Microsoft [43]
make an attractive alternative for parallel processing and high speed computation. It was
decided to port simulation to .NET framework. Another reason was to exploit parallel
processing for high speed computation that will bring this work one step close to its real
time implementation. The simulation program uses C++ and is appropriate for its
conversion into parallel program. A Parallel Patterns Library (PPL) of .NET Framework 4 is
available for users to parallelize computation processes in C++. Within .NET Framework 4,
a „Concurrency Runtime‟ is specially designed for multi-core applications [44].
56
In this chapter, multi-core architecture will be introduced and several available
implementations of multi-core programming will be provided. The comparison between
C++ simulation results and MATLAB simulation results will be performed. The C++
program will be analyzed, partitioned, parallelized and optimized for parallel execution. The
speedups gained by several program optimization methods will be shown and compared.
5.1 Multi-core Architecture
Before multi-core technology, speedup has been achieved by increasing clock speed.
Over the past decades, clock speeds have been increasing exponentially. When CPU clock
speed rose into the range of 3-4 GHz, the amount of electrical power generated prohibits it
from going faster [45]. Issues such as power consumption, heat dissipation and leakage
current make it impossible to rely only on the increasing clock speed. The new trend is to
introduce multi-core processors [44]. Semiconductor manufacturers are on a band wagon of
multi-cores and producing multi-core processors, many core processors, multi-core Digital
Signal Processors (DSPs), Graphic Processors Units (GPUs), and General Purpose Graphic
Processors Units (GPGPUs) etc. These multi-core processors will also require use of parallel
processing.
5.1.1 Advantage of Multi-core Computing
For single-core processors, only a single instruction can be executed at a time. This
computing pattern is called serial computation. In serial computation, the execution time of
a specific program highly depends on the CPU‟s clock speed. Faster the clock speed is
higher the number of operations performed in a given time. Compared to serial
57
computation, multi-core architecture provides users an opportunity to perform
computations in parallel. A basic parallel computation process is shown in Figure 5.1.
CPU1
Program CPU2
CPU3
Figure 5.1: Parallel Computation
It can be seen that a program can be partitioned into number of processes and each
processes is executed by a CPU. Therefore, multiple processes execute concurrently
minimizing the program execution time. Generally speaking, there are two ways of parallel
processing a program as it will depend on the structure of the program. A user can identify
parts of the program that can be executed in parallel or compiler can identify any inherent
parallelism hidden in the program. A user can exploit parallelism at data, loop and function
level. A user needs to identify part of the code that is independent of the data and
instructions. The user can then exploit data level parallelism by executing independent
instructions in parallel. Some applications may have loops and if they have independent data
then loop level parallelism can be exploited. A loop should not be dependent on results
from previous loops. In other cases, computations may be heavily dependent on each other.
Therefore in order to execute the next loop, the previous loop has to complete first. But
parallelism can still be applied because within a specific loop, there may be independent
functions or processes that could be executed in a parallel fashion giving a function level
parallelism. Functional level parallelism can also be characterized by commonly known term
of Multiple Instructions Multiple Data (MIMD).
58
An entire program needs to be partitioned into number of independent processes which
can be executed independently. A process can be further partitioned into number of threads
which are group of instructions.
Processes are assigned to different CPUs and threads are in the waiting queue for the
next execution cycle. The job of assignment is performed by a scheme called process
scheduler. Each process executes as a part of a program. These processes are independent
with each other; therefore they can be executed concurrently. The partitioning process is
shown in Figure 5.2.
Thread1 Thread1 Thread1 Thread1
Thread2 Thread2 Thread2 Thread2
Threadi Threadi Threadi Threadi
Core 1 Core 2 Core 3 Core n
Process Scheduler
Process Process Process Process

1 2 3 n
Figure 5.2: Program partitioning process
5.1.2 Overhead behind Multi-core Computing
Multi-core parallel programming can result in communication overhead. When a
program is partitioned into different tasks or processes, data pieces have to be transferred
into local memories of different CPUs from global memory or vice versa. Therefore the
effort of data transferring and writing back to different memories is considered as an
overhead.
59
The amount of computation of a process has to be large as compared to the overhead
generated by partitioning. The larger a process gets, the less overhead becomes relatively.
It is important to note that an individual partition should always be as large as possible in
order to offset the cost of overhead.
5.1.3 Multi-core CPU

TM
In this thesis, Intel® Core i5-520M is selected as the multi-core processor for GA
based MMRAC F-16 flight surface control system. Some of the important specifications of
i5 are listed in Table 5.1 [37].
Table 5.1: Specifications of Intel® Core TM i5-520M
Processor Number i5-520M
Number of Cores 2
Number of Threads 4
Clock Speed 2.4 GHz
Max Turbo Frequency 2.933 GHz
Intel® Smart Cache 3 MB
Instruction Set 64-bit
5.2 F-16 Flight Surface Control System Simulation in C++
A new simulation program in C++ is developed with similar structure as discussed in
Chapter 3. For the ease of illustration, only pitch position tracking results will be shown in
this chapter. The new C++ program shows pitch position tracking trajectories similar to the
one previously obtained using MATLAB simulation. One of the limitations of .NET
Framework 4, is that figures could not be plotted by the environment itself. In order to show
60
the final tracking trajectory, tracking data is saved in a „.dat‟ file and MATLAB is used again
to call the „.dat‟ file and to show data graphically. The pitch position tracking of GA based
MMRAC control system is shown in Figure 5.3.
Figure 5.3: Pitch Control Tracking of GA based MMRAC system in C++
The objective of exploiting available multi-core technology is to gain as much speedup
as possible. Therefore, the execution time of this C++ simulation program has to be
recorded as a base line for future coding optimization. The simulation program was executed
ten times and its execution time of each run was recorded. The average time is saved as the
final execution time. The execution time of future parallelized programs will also be
computed in similar fashion. For the serial C++ program, the execution time is shown in
Table 5.2.
61
Table 5.2: Execution Time of Serial C++ Simulation
Run Number Execution Time (s)
1 11.625
2 11.001
3 9.488
4 10.237
5 12.062
6 11.984
7 11.603
8 10.580
9 10.925
10 12.156
Average Time 11.226
5.3 Analysis of the C++ Code
The flight surface control system contains main „object body‟ as the major loop as was
shown in Figure 3.3. The „object body‟ contains code for Runge-Kutta to solve partial
differential equations iteratively in numerical fashion. The „object body‟ needs to iterate
18689 times. The program was explored to uncover opportunities for exploitation of the
parallel processing. It was discovered that every execution of „objects body‟ required
computation of fourteen independent functions. It should also be noted that it was repeated
18689 times. Therefore the program provided an opportunity to exploit function level
parallelism. Fourteen independent functions were coded to exploit function level parallelism.
62
.NET Framework 4 provides Parallel Pattern Library (PPL) which enables exploitation
of parallel processing. This library contains several keywords including „parallel_for‟ and
„parallel_invoke‟. „parallel_for‟ is perfect for SIMD which runs a single instruction a number
of times over multiple data. „parallel_invoke‟ invokes several processes at the same time and
all of them can be executed in parallel. Therefore, „parallel_invoke‟ feature is used and
program was restructured accordingly. The computation time of the new structured parallel
program reduced from 11.226 to 4.622. Figure 5.4 shows percentage of CPU utilization for
execution of serial program. Similarly Figure 5.5 shows percentage of CPU utilization for
execution of parallel program. It can be seen from both figures that the CPU utilization
jumps from 19% to almost 100% in case of parallel program. Table 5.3 shows execution
times of newly structured parallel program. It can be seen that the average execution time is
4.622 seconds.
Figure 5.4: CPU Usage of Serial Program
63
Figure 5.5: CPU Usage of Parallel Program
Without changing the structure of the program, the function level parallelized C++ code
performs already a lot better than its serial counterpart.
64
Table 5.3: Execution Time of Parallelized single model MRAC C++ Simulation
Run Number Execution Time(s)
1 4.688
2 4.567
3 4.958
4 4.214
5 4.597
6 4.855
7 4.721
8 4.221
9 4.889
10 4.513
Average Time 4.622
Speedup 2.429
Next, new parallel program is further explored for reducing execution time via
optimization of cache hits, memory allocation, increase in parallelized functions and
reducing any other repeated processes.
5.4 Restructure of Parallel Program
5.4.1 Cache hits and memory allocation
Cache is a kind of memory that transparently stores data so that future requests for that
piece of data can be accessed in reduced time. Cache provides access time faster than the
memory and slower than on-chip registers. The data storage can be structured in a pyramid
65
form as shown in Figure 5.6. Higher the storage option is in the pyramid; faster the data can
be accessed. Data can be saved into cache right after its computation and it remains in cache
until it is replaced by other data. This replacement is performed when either no more
requests for this data occurs in a certain time or space is needed by some other processes.
CPU
Cache
Memory
Figure 5.6: Pyramid Data Storage
Generally modern processors are organized in three levels of caches namely L1, L2 and
L3. A piece of data in L1 which gets no more requests is downgraded into L2 and then to L3
if it is not accessed by the processor on regular basis. It could be sent to the main memory if
it is not used for certain duration. One way to increase its execution speed is to increase data
fetching from the cache. This will require a rearrangement of the entire program.
Consider following code
1 parameterA= processA( );
2 parameterB= processB( );
3 parameterC=processC( );
4 processD( ); // independent of A,B or C
5 processE( );//independent of A,B or C
… …
n parameterF=function (parameterA, parameterB, parameterC);
66
In this code „parameterA‟, „parameterB‟ and „parameterC‟ are calculated at the beginning
of this code and then they are fetched again after some time as calling data to execute four
functions. In this case these parameters are not used for some time and might have moved
back to the main memory. They were called again and then they need to be moved to L1
cache for further processing of functions. This data fetching after long time will contribute
to unnecessary waste of time especially if it is performed 18698 times. Therefore, in order to
increase cache hits, the code can be rearranged as:
1 parameterA= processA( );
2 parameterB= processB( );
3 parameterC=processC( ) ;
4 parameterF=function (parameterA, parameterB, parameterC);
5 processD( ); // independent of A,B or C
6 processE( );//independent of A,B or C
… …
Similar to cache hits, memory allocation is another important issue in data transfer
process especially for large amount of data or large number of repeated operations. This is
true due to availability of multiple memories such as global, local or on-chip memories.
Every single modification saves a bit of time on data fetching and writing back. If this saving
is achieved on every of the 18689 iterations then it can lead to lot of savings in the
computation time. The primary idea is to allocate memory space for data in such a memory
space that can reduce data communication time. There are fourteen functions that are
executed in parallel. Ten of the fourteen functions have approximately 108 pieces of data
that are stored in the form of look up tables inside the function itself. Data for the pointer
function „*damp‟ has the following form:
67
1 functionA( ) {
2 double coefficient matrix [9][12]; //initiate a 9*12 matrix
3 parameterB= processB( ); // a number from matrix is needed
4 parameterC=processC( ) ; //a number from matrix is needed
… …
5 parameterD=processD;// a number from matrix is needed
6 Return value; };
Therefore this data will be moved first from one memory storage area to another. It will
also require rebuilding of this data structure in every function call. If there are 18689 calls
then there will be lot of execution time allocated to the data initialization. In C++, data
claimed within “{ }” needs to be initialized every time the function gets called. In another
word, any data initialization within a function is defined in local memory. As an alternative,
data could also be initialized outside a function as global data. This kind of data only needs
to be defined once and would be available until the entire program is terminated. One idea is
to move data access from a local memory to a global memory so it can be accessed without
any kind of initialization process. This movement and initialization at one time only will save
enormous amount of time especially if it is called 18689 times. A modified version of this
9×12 data matrix used as a look up table will have the following form:
1 double coefficient matrix [9][12]; //initiate a 9*12 matrix

2 functionA( ) {
3 parameterB= processB( ); // a number from matrix is needed
4 parameterC=processC( ) ; //a number from matrix is needed
… …
5 parameterD=processD;// a number from matrix is needed
6 Return value; };
With this change in look up table, the compiler will simply fetch the matrix from the
global memory for this function „functionA‟ only once. This function runs 18689 times
68
contributing towards enormous time saving. This flight surface control program has ten such
functions and this allocation of data at another location results in computational time
savings.
5.4.2 Increasing Parallelism by Reducing Repeated Processes
Functions utilize a number of parameters and series of instructions to compute an array
of results as shown in Figure 5.7.
Line 1
Parameters Return Values
Line 2
Line 3
……
Line N
Figure 5.7: Architecture of a calling Function
The main idea is to detect whether there are other series of instructions that conform the
pattern in Figure 5.7 and are a candidate to become a function. Further analysis of the flight
surface controller revealed following code inside the main code of „object body‟ and was
being executed 18689 times. This code was formed into a function and was moved out of
the „object body‟. This movement of data resulted in avoiding execution of this code 18689
times. As an example, the following codes computes one value („parameterX‟) based on two
parameters („a‟ and „b‟).
69
1 parameterA=processA(a, b) ;
3 parameterB= processB(a, b);
4 parameterC=processC(a, b) ;
… …//every instruction depends on a and b
5 parameterN=processN(a,b);
6 parameterX=processX(parameterA,….);
It could be transformed into one function as a new calling function that can be executed
in parallel.
One of the goals of the parallel processing is to keep every core busy all the time. The
other aspect is to partition code uniformly so all cores are busy. Therefore, it will be
necessary to keep equal amount of code and reduce any unnecessary data transfer.
Another objective is to reduce unnecessary assignment of constant values inside the loop
especially if the loop is being executed thousands of time. The main idea behind this is to
make sure constant values or values that are not changing inside the loop needs to be moved
out of the loop. Any parameter that is shared with several (ten in this example) functions
needs to stay in the main function. It will avoid unnecessary loading of the sharable
parameters. For example, within fourteen functions, ten of them need to calculate indexes to
fetch data from look up tables. These indexes are the same for all functions. Therefore this
index calculation process should be executed in the main function and just transfer the
indexes to the calling functions. With this modification, the process only needs to be
calculated once instead of ten times and repeated 18689 times.
70
5.4.3 Other Possible Code Optimization Methods
There are other possible code modifications and optimization techniques and four of
them are given as [40]:
1. Parameters calculated by internal built-in functions such as „cos‟, „sin‟ and „abs‟ etc.
could be saved as another parameter in order to avoid their repeated computation.
This scheme has been exploited in this flight surface control system.
2. Reduce „if‟, „else‟ statements as these conditional branch processes can slow the
program execution. This is due to the use of pipeline execution of instructions by the
most modern processors.
3. Remove as much as possible any data initializations such as constant matrices in
order to reduce data communication.
4. Reduce parameter numbers that needs to be transferred from one calling functions
to another in order to decrease data communication. This will require truncation of
code in partitioning process at appropriate locations to reduce data communications.
It is important to note that every code optimization method is sensitive to
communication overhead. For a specific piece of program, some methods work much more
effectively than others. Careful computation time optimization is necessary. Repeated
experiments should be planned out and execution time should be recorded in order to select
the best optimized solution.
5.5 Performance of Optimized Parallel Program
After repeated experiments and comparisons, the entire program is restructured and
optimized to a level that is parallelized to the most extent as possible. The screen shot of the
71
execution result of pitch rotation control system with single model MRAC is shown in
Figure 5.8.
Figure 5.8: Snapshot of Execution Result
The execution time of the pitch control program with single MRAC controller was
recorded and is shown in Table 5.4.
72
Table 5.4: Execution Time of Optimized Parallel single model MRAC C++ Simulation
1 3.870
2 3. 958
3 3.540
4 3.931
5 3.597
6 3.558
7 3.712
8 3.690
9 3.665
10 3.814
Average Time 3.734
Speedup 3.005
The total speedup before optimization was 2.426 and after optimization and code
restructuring it increased to 3.006.
The execution time of GA based MMRAC controlled pitch control system is similar to
the single model MRAC system since the genetic algorithm only performed five times during
the entire control process. The execution time for GA based MMRAC controlled C++
program is shown in Table 5.5.
73
Table 5.5: Execution Time of Optimized Parallel GA based MMRAC C++ Simulation
1 3.783
2 3. 690
3 3.441
4 4.069
5 3.673
6 3.882
7 3.406
8 3.557
9 3.601
10 3.788
Average Time 3.689
Speedup 3.043
Execution times of optimized single model MRAC program, optimized GA based
MMRAC program and single model MRAC program before optimization is given by Table
5.6.
74
Table 5.6: Comparison of execution time for different serial and parallel programs
Serial Program Parallel Program
GA Single Single model Optimized Optimized

based model MRAC before Single model GA based
MMRAC MRAC optimization MRAC MMRAC
Execution Time 11.226 11.220 4.622 3.734 3.689
(seconds)
Speed up none none 2.428 3.005 3.043
The pitch rotation control tracking of the parallelized C++ program is shown in Figure
5.9.
Figure 5.9: Pitch tracking using serial and parallel programs
It can be seen from Figure 5.9 that pitch rotation tracking generated by optimized
parallel program shows almost the same result as the serial program for GA based MMRAC
controlled pitch rotation control system. It is because that during parallelization and
optimization of the program, the computation has not been changed. Only the structure of
the program has been modified and optimized for better performance.
75
Chapter 6
Conclusions and Future Work

6.1 Conclusions
The work in this thesis aims at the improvement of the computational performance of
the Model Reference Adaptive Controller specifically for F-16 surface control system. MIT
rule was selected to adjust parameters. Three rotation motions, pitch, roll and yaw are
analyzed. It was discovered that the yaw control takes longer time to stabilize.
The idea of Multiple Model Reference Adaptive Control was explored and Genetic
Algorithm based approach is proposed for model selection. GA based MMRAC was
developed and was also compared with the single model MRAC. GA based MMRAC
showed significant improvement in all three rotation position tracking trajectories.
It is certain that multi-core programming is a powerful technology which is able to
improve the performance of computationally intensive applications. The final goal of this
thesis is to partition the flight surface control C++ code and run it with a combination of
parallel and serial pattern. The key issue is to find the balance point between parallel and
serial processing so that the overall performance could be improved to its fullest extent.
MATLAB simulation was converted into C++ under .NET framework in order to
exploit parallel processing. The parallel library of .NET framework is used to modify the
program and the execution time of the parallel code was optimized using several
76
optimization approaches. The optimized program performs much better and the execution
time reaches 3.75 seconds with a speed up of 3.006. The final execution time of the GA
based MMRAC flight surface control system is around is around 3.75 seconds giving a
response time of 20.83 ms using this off-the-shelf processor in a desktop computer.
6.2 Future Work
The performance of yaw position tracking could be improved by modifying aerodynamic
conditions. The condition used in the simulation process is steady trim condition. It involves
no disturbance on the vertical axis of the aircraft. On the other hand, yaw rotation motion
results in not only change in yaw angle but also change in roll angle. It is a combination of
two control processes. Therefore, beside the introduction of MMRAC, a new control
scheme could be developed especially for yaw position tracking.
The CPU used in the thesis is Intel® i5 which has only 4 cores. At the same time, only
four functions could be executed in parallel while other ten functions wait for their
execution. It is possible to use other processors with more than four cores. For example,
IBM cell has nine cores that may provide better results. Moreover Nvidia‟s GPU can also be
experimented and exploited. Another possible future work would be to map this design onto
FPGAs as this control algorithm uses look up table based approach and has fixed number of
iterations. One final future work would be to reduce single precision that may give better
computation time.
77
References
1. K.J. Astrom and B. Wittenmark, Adaptive Control, 2nd, Mineola, N.Y.: Dover
Publications, 2008.
2. Petros A. Ioannou, Jing Sun, Robust Adaptive Control, Upper Saddle River, N.J.: PTR
Prentice-Hall, 1996.
3. Naira Hovakimyan, Chengyu Cao, “L1 Adaptive Control Theory: guaranteed robustness
with fast adaptation”, Philadelphia: Society for Industrial and Applied Mathematics,
2010.
4. Nvidia, Getting Start with CUDA, Retrieved from
http://www.nvidia.com/content/cudazone/download/Getting_Started_w_CUDA_Trai
ning_NVISION08.pdf, 2008.
5. IBM, Cell Broadband Engine Architecture, Retrieved from https://www-
01.ibm.com/chips/techlib/techlib.nsf/pages/main, 2007.
6. Alessandro Astolfi, Dimitrios Karagiannis, Romeo Ortega, Nonlinear and Adaptive
Control with Applications, London: Springer, 2008.
7. Alessandro Astolfi, Nonlinear and Adaptive Control: Tools and Algorithms for the User,
London: Imperial College Press, 2006.
8. H.C. Cho, M.S. Fadali, K.S. Lee, N.H. Kim, “Adaptive Position and Trajectory Control
of Autonomous Mobile Robot Systems with Random Friction”, IET Control Theory &
Applications, Vol. 4 Issue 12, p2733-2742, 2010.
9. Suresh M. Joshi, Gang Tao, Parag Patre, “Direct Adaptive Control using an Adaptive
Reference Model”, International Journal of Control, Vol. 84 Issue 1, p180-196, 2011.
78
10. Daniel E. Miller, Naghmeh Mansouri, “Model Reference Adaptive Control Using
Simultaneous Probing, Estimation and Control”, IEEE Transactions on Automatic Control,
Vol. 55 Issue 9, p2014-2029, 2010.
11. J. X. Xue, “Stability and Robustness analysis of MIMO MRAC Using Kp=L2 D2 S2
Factorization”, International Journal of Systems Science, Vol. 39 Issue 3, p265-278, 2008.
12. Kumpati S Narendra et al,. “Adaptive Control Using Multiple Models”, IEEE Trans. on
Automatic Control, Vol.42, No.2, pp-171-187, Feb 1997.
13. Kamalasadan S., Ghandakly Adel A., “A Neural Network Parallel Adaptive Controller
for Fighter Aircraft Pitch-Rate Tracking”, IEEE Transactions on Instrumentation &
Measurement, Vol. 60 Issue 1, p258-267, 2011.
14. Brian L. Stevens, Frank L. Lewis, Aircraft Control and Simulation, 2 nd, Hoboken, N.J.:
John Wiley & Sons, Inc, 2003.
15. NASA, Aeronautics Tutorial, http://quest.arc.nasa.gov/aero/virtual/demo/aeronautics-
/tutorial/motion.html.
16. NASA, Airplane Control Surfaces, http://ze-engineer.blogspot.com/2010/06/airplane-
control-surfaces.html, 2010.
17. Youtube, How To Make A Right Turn in a Airplane, http://www.youtube.com/watch?-
v=KEx_DYxjlqU, 2008.
18. Michael Sanibel, “Quest to Build a Better Fighter”, Aviation History, Vol. 21 Issue 3, p48-
53, 2011.
19. A.A. El-Mahallawy, H.A. Yousef, M.I. El-Singaby, A.A. Madkour, A.M. Youssef,
“Robust Flight Control System Design using Loop-Shaping and Recessive Trait
Crossover Genetic Algorithm”, Expert Systems with Applications, Vol. 38 Issue 1, p169-174,
2011.
79
20. Chao Wang, Yifan Kang, Tiantong Tang, “Probe-type Time-of-Flight Momentum and
Energy Mapping System”, Optik-International Journal for Light & Electron Optics, Vol. 122
Issue 6, p544-548, 2011.
21. Y. Lee, S. Kim, H. Koo, J. Kim, J. Suk, “System Identification and Stability Evaluation
of An Unmanned Aerial Vehicle From Automated Flight Tests”, KSME International
Journal, Vol. 17 Issue 5, p654-667, 2003.
22. Wolfgang Schuster, Washington Ochieng, “Airport Surface Movement –Critical Analysis
of Navigation System Performance Requirements”, Journal of Navigation, Vol.64 Issue 2,
p281-294, 2011.
23. Gunter Hommel, Huanye Sheng, Embedded Systems-Modeling, Tchnology and
Application, Netherlands, Springer, 2006.
24. Michael Schiebe, Saskia Pferrer, Real-Time Systems Engineering and Application,
Norwell, MA: Kluwer Academic Publishers Group, 2000.
25. John A. Wise, V. David Hopkin, Daniel J. Garland, Handbook of Aviation Human
Factors, 2nd ed, Boca Raton: CRC Press, 2010.
26. Christopher Fielding, Advanced Techniques for Clearance of Flight Control Laws,
Heidelberg Berlin: Springer, 2002.
27. Brian D. O. Anderson, Thomas Brinsmead, Daniel Liberzon, A. Stephen Morse,
“Multiple Model Adaptive Control with Safe Switching”, International Journal of Adaptive
Control and Signal Processing, 2001.
28. K.S. Narendra, J. Balakrishnan, “Adaptive Control using Multiple Models”, Automatic
Control, Vol. 42 Issue 2, p171-187, 1997.
80
29. P.S. Maybeck, R.D. Stevens, “Reconfigurable Flight Control Via Multiple Model
Adaptive Control Methods”, Aerospace and Electronic Systems, Vol. 27 Issue 3, p470-480,
1991.
30. G.C. Goodwin, D.Q. Mayne, “A Parameter Estimation Perceptive of Continuous Time
Model Reference Adaptive Control”, Automatica, Vol. 23 Issue 1, p57-70, 1987.
31. R. Murray- Smith, T.A. Johansen, Multiple Model Approaches to Modeling and Control,
Bristol, PA: Taylor & Francis Inc, 1997.
32. B. Jung, Y. Kim, C. Ha, “Fault Tolerant Flight Control System Design using a Multiple
Model Adaptive Controller”, Journal of Aerospace Engineering, Vol. 223 Issue 1, p39-50,
2009.
33. Boris Mirkin, Per-Olof Gutman, “Robus Output-Feedback Model Reference Adaptive
Control of SISO Plants With Multiple”, IEEE Transactions on Automatic Control, Vol. 53
Issue 10, p2414-2419, 2008.
34. M.K. Ciliz, A. Cezayirli, “Increased Transient Performance for the Adaptive Control of
Feedback Linearizable System using Multiple Models”, International Journal of Control, Vol.
79 Issue 10, p1205-1215, 2006.
35. K. F. Man, K. S. Tang, S. Kwong, “Genetic Algorithms: Concepts and Applications”,
IEEE Transactions on Industrial Electronics, Vol. 43 Issue 5, p519-534, 1996.
36. D. B. Varley, E. K. Burke, “A Genetic Algorithms tutorial tool for Numerical Function
Optimization”, ACM SIGCSE Bulletin, Vol. 29 Issue 3, p27-30, 1997.
37. Andrew Hunter, “Crossing Over Genetic Algorithms: The Sugal Generalized GA”,
Journal of Heuristics, Vol. 4 Issue 2, p179-192, 1998.
38. M.M. Arafa, F.A. Omara, “Genetic Algorithms for Task Scheduling Problem”, Journal of
Parallel and Distributed Computing, Vol. 70 Issue 1, p13-22, 2010.
81
39. Wilson Rivera, “Scalable Parallel Genetic Algorithms”, Artificial Intelligence Review, Vol. 16
Issue 2, p153-168, 2001.
40. Jagannathan Gomatam, David Reynolds, “Stochastic Modeling of Genetic Algorithms”,
Artificial Intelligence, Vol. 82 Issue 1-2, p-303-330, 1996.
41. Stephen W. Kechler, Kunle Olukotun, H. Peter Hofstee, Multicore Processors and
Systems, Austin, TX: Springer, 2009.
42. Max Domeika, Software Development For Embedded Multi-core Systems-A Practical
Guide for Using Embedded Intel® Architecture, Burlington, MA: British Library
Cataloguing-in-Publication Data, 2008.
43. S.H. Hung, C.H. Tu, W.L. Yang, “A Portable, Efficient Inter-core Communication
Scheme for Embedded Multicore Platforms”, Journal of Systems Architecture, Vol.57 Issue
2, p193-205, 2011.
44. Nir Shavit, “Data Structure in the Multicore Age”, Communications of the ACM, Vol. 54
Issue 3, p76-84, 2011.
45. Hongyang Sun, Yangjie Cao, Wen-jing Hsu, “Efficient Adaptive Scheduling of
Multiprocessors with Stable Parallelism Feedback”, IEEE Transactions on Parallel&
Distributed Systems, Vol.22 Issue 4, p594-607, 2011.
82

Czar Kowski 02 A

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Czar Kowski 02 A

Uploaded by

Copyright:

Available Formats

A Thesis

Multi-Core Implementation of F-16 Flight Surface Control System Using GA Based

Multiple Model Reference Adaptive Control Algorithm

Submitted to the Graduate Faculty as partial fulfillment of the requirements

for the Master of Science Degree in Electrical Engineering

The University of Toledo

Multi-Core Implementation of F-16 Flight Surface Control System Using GA Based

Multiple Model Reference Adaptive Control Algorithm

Submitted to the Graduate Faculty as partial fulfillment of the requirements

The University of Toledo

implementation of the proposed algorithm on a 4-core-Architecture of Intel® i5 CPU. The

optimization techniques were used to achieve the maximum speed up.

Hong Wang for their enthusiastic guidance through this endeavor.

1.1 Background .................................................................................................... 1

1.2 Research Approach ........................................................................................ 4

2. Model Reference Adaptive Control (MRAC)…………………………………………6

2.1 Introduction to Adaptive Control .................................................................... 6

2.2 Definitions and Concepts................................................................................ 7

2.3 Examples of Adaptive Controller ................................................................... 8

2.4 Model Reference Adaptive Control (MRAC) ................................................. 9

2.4.2 MIT rule ........................................................................................................... 12

2.4.3 Normalized MIT rule ..................................................................................... 13

2.4.4 A MRAC Example ......................................................................................... 14

3. F-16 Flight Surface Control Model 16

3.2 Mathematical Model of F-16 Aircraft ........................................................... 19

3.2.1 MRAC controller of F-16 Aircraft ............................................................... 22

3.3 Simulation Architecture................................................................................ 25

3.3.1 Simulation Model Building Blocks ............................................................... 26

3.3.2 MATLAB Flight Model ................................................................................. 26

3.3.3 Initial State of Pitch Rotation System .......................................................... 28

3.3.4 Initial State of Roll Rotation System ............................................................ 29

3.3.5 Initial State of Yaw Rotation System ........................................................... 30

3.4 MRAC based F-16 Flight Surface Control Simulation .................................. 31

3.4.1 Pitch Rate Control .......................................................................................... 31

3.4.2 Runge-Kutta 4th Order Method .................................................................. 32

3.4.3 Roll Control ..................................................................................................... 35

3.4.4 Yaw Control .................................................................................................... 36

4. Genetic Algorithm Based Multiple Model MRAC………………………………….38

4.1 Multiple-Model MRAC (MMRAC) .............................................................. 39

4.1.1 The need for MMRAC................................................................................... 39

4.1.2 Multiple-Model Reference Adaptive Control ............................................. 40

4.1.3 Model switching .............................................................................................. 41

4.2 Genetic Algorithm (GA) ............................................................................... 42

4.2.1 Basics of GA.................................................................................................... 42

4.3 GA based MMRAC ...................................................................................... 47

4.3.1 MMRAC mapping onto flight surface control ........................................... 47

4.3.2 GA mapping onto flight surface control system ....................................... 49

4.4 MMRAC Controlled flight surface control system simulation ...................... 50

5. Parallel Processing Using Multi-Core……………………………………………….56

5.1 Multi-core Architecture ................................................................................ 57

5.1.1 Advantage of Multi-core Computing........................................................... 57

5.1.2 Overhead behind Multi-core Computing ................................................... 59

5.1.3 Multi-core CPU............................................................................................... 60

5.2 F-16 Flight Surface Control System Simulation in C++ ................................ 60

5.3 Analysis of the C++ Code ............................................................................ 62

5.4 Restructure of Parallel Program .................................................................... 65

5.4.1 Cache hits and memory allocation ............................................................... 65

5.4.2 Increasing Parallelism by Reducing Repeated Processes ......................... 69

5.4.3 Other Possible Code Optimization Methods ............................................. 71

5.5 Performance of Optimized Parallel Program ................................................. 71

6. Conclusions and Future Work……………………………………………………….76

6.1 Conclusions .................................................................................................. 76

6.2 Future Work ................................................................................................. 77

3-2 Degree limits of various deflections and actuators .................................................................20