The HOBIC Dissertation

HUMAN OPERATOR BASED INTUITIVE
CONTROLLER
(HOBIC)

Filipe Leandro de F. Barbosa

Research dissertation submitted in partial fulfilment of the requirements
for the degree of MSc in Applied Process Control

School of Chemical Engineering and Advanced Materials
Newcastle University
August 2008
ii
Abstract

A recent study [1] revealed that the great majority of the control loops that operate in Industry
use the PID (Proportional-Integral-Derivative) technology. Furthermore, the study has shown
that more than one third of these loops were switched to manual for a considerable period of
time, indicating poor behaviour of the controllers performance. As is well known, Industry
normally has a great resistance to applying newly developed technology. The gap between the
Industry and the Process Control Theory remains unchanged over the years, as was also
reported in the study, indicating that the Industry is looking for simple and easy to use
technologies. This can be a reason why the PID is still the main applied control technique.

The present research offers an alternative control scheme that intends to be a step towards
introducing a new technology in the Industry. The controller developed aims to emulate the
Human Operators actions when manually controlling SISO systems, subject to disturbances.
The operators are the end users of the controllers. Therefore, if they are able to understand how
the control scheme works it is less likely that they will switch them to manual, during normal
conditions. The developed control scheme is based on an intuitive hypothetical model that
describes the way the Human Operator (HO) acts in a manual control loop, generating the
Human Operator Based Intuitive Controller (HOBIC). Hence, it is a model-based controller.
The HOBIC is then extended using the Fuzzy Logic theory so it can be more flexible and easier
to understand, yielding the Fuzzy-HOBIC.

A Graphics Interface is implemented in MATLAB, version 7.2, to simulate a practical nonlinear
application of the developed control scheme. The results show that the hypothetic model created
for the HOs actions is appropriate, since the generated control actions by the HOBIC and
Fuzzy-HOBIC can approximate those of the operator. A technique for the automatic tuning of
the Fuzzy-HOBIC using a Genetic Algorithms approach is presented. The tuning does not
require the model of the process, as it is based on the manual operation actions. The control
signal generated has the same discontinuous nature of the HOs one. Thus, it is likely to be
recognised as a manual operation and easily understood by the operator.

iii
List of Figures

Figure 2.1: Fictitious representation of a Manual control signal compared with a generated control signal
using a model-free approach................................................................................................................ 5
Figure 3.1: Intuitive HO behaviour when in Mode A of operation. ........................................................... 10
Figure 3.2: Intuitive HO behaviour when in Mode B of operation............................................................. 10
Figure 4.1: Variables used to encapsulate the HO's behaviour in the HOBIC. .......................................... 14
Figure 4.2: Limits and their tags established for the Slope (S) between the PV trend and SP. .................. 17
Figure 4.3: Division of the output delta control signal into defined intervals. ........................................... 17
Figure 4.4: How the deltaAction tags are translated into control actions. .................................................. 19
Figure 4.5: Example of the HOBIC operation in a hypothetic control loop. .............................................. 20
Figure 4.6: Fuzzy-HOBIC Linguistic variables.......................................................................................... 23
Figure 4.7: Fuzzy-HOBIC Inference System general description. ............................................................. 26
Figure 4.8: Fuzzy-HOBIC output variable description. ............................................................................. 26
Figure 5.1: Chromosome definition of a hypothetic individual X from the population. ............................ 31
Figure 5.2: Example of single and double-point crossover. ....................................................................... 33
Figure 5.3: Example of the real-value mutation being applied in an offspring (the mutation rate is 50%).
........................................................................................................................................................... 33
Figure 5.4: A general genetic algorithm block diagram. ............................................................................ 35
Figure 5.5: Roulette wheel selection method. ............................................................................................ 36
Figure 5.6: SUS selection method. ............................................................................................................. 37
Figure 5.7: Description of the implemented GA to solve the Fuzzy-HOBIC tuning problem. .................. 39
Figure 6.1: Process Control Application scheme: controlling the level in a tank. ...................................... 40
Figure 6.2: GUI that simulates the DCS that operates the tank level system. ............................................ 42
Figure 6.3: GUI Menu in detail. ................................................................................................................. 44
Figure 6.4: HOBIC parameters GUI........................................................................................................... 44
Figure 6.5: Fuzzy-HOBIC parameters MATLAB FIS editor. .................................................................... 45
Figure 6.6: Tank Level Parameters definition. ........................................................................................... 45
Figure 6.7: Generating manual operations for a level disturbance (20% up). ............................................ 47
Figure 6.8: Manual Operation: step up test (20%)...................................................................................... 48
Figure 6.9: Manual Operation: step down test (20%)................................................................................. 48
Figure 6.10: Manual Operation: disturbance rejection up (20% valve V
2
- closing). ................................. 49
Figure 6.11: Manual Operation: disturbance rejection down (20% valve V
2
- opening)............................ 49
Figure 6.12: Using parameter N
5
to determine whether the deltaAction is "small" or not. ........................ 52
Figure 6.13: Subpopulations Evolution per generation. ............................................................................. 55
Figure 6.14: Subpopulations Evolution per generation (showing the last few generations)....................... 55
Figure 6.15: First convergence criterion evolution per generation. ............................................................ 56
Figure 6.16: Objective values evolution for the best individuals. .............................................................. 56
Figure 6.17: Where the best individuals come from?................................................................................. 57
Figure 6.18: Best individual (after the GA terminated) vs. Manual Operation (step up). .......................... 57
iv
Figure 6.19: Best individual (after the GA terminated) vs. Manual Operation (step down). ..................... 58
Figure 6.20: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Step up test. .................... 58
Figure 6.21: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Step down test. ............... 59
Figure 6.22: Results of three GA tunings obtained (Step-up tests). ........................................................... 60
Figure 6.23: Results of three GA tunings obtained (Step-down tests)........................................................ 60
Figure 6.24: Slope (input variable) for Fuzzy-HOBIC 1. ........................................................................... 61
Figure 6.27: ErrorPercentage (input variable) for Fuzzy-HOBIC 1. .......................................................... 62
Figure 6.30: DeltaCtrlAction (output variable) for Fuzzy-HOBIC 1. ........................................................ 63
Figure 6.33: Fuzzy-HOBIC tuned for SP-tracking (dashed lines) vs. Manual Operation (solid lines).
Disturbance Rejection up test. ........................................................................................................... 65
Disturbance Rejection down test. ...................................................................................................... 65
Figure 6.35: Subpopulations Evolution per generation. ............................................................................. 66
Figure 6.36: First convergence criterion evolution per generation. ............................................................ 66
Figure 6.37: Objective Values evolution for the best individuals............................................................... 67
Figure 6.38: Where the best individuals come from?................................................................................. 67
Figure 6.39:Best individual (after the GA has terminated) vs. Manual Operation (Disturbance up). ........ 68
Figure 6.40: Best individual (after the GA has terminated) vs. Manual Operation (Disturbance down). .. 68
Figure 6.41: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection up
test...................................................................................................................................................... 69
Figure 6.42: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection
down test............................................................................................................................................ 70
Figure 6.43: Results of three GA tunings obtained (Disturbance Rejection up tests). ............................... 70
Figure 6.44: Results of three GA tunings obtained (Disturbance Rejection down tests)............................ 71
Figure 6.51: DeltaCtrAction (output variable) for Fuzzy-HOBIC 4. ......................................................... 73
v
Figure 6.54: Fuzzy-HOBIC tuned for Disturbance Rejection (dashed lines) vs. Manual Operation (solid
lines). SP-tracking up test. ................................................................................................................. 75
lines). SP-tracking down test. ............................................................................................................ 75
Figure 6.56: How to obtain the HOBIC parameters from the Fuzzy-HOBIC input variables.................... 77
Figure 6.57: How to obtain the HOBIC parameters minDelta and maxDelta. ........................................... 77
Figure 6.58: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step up test. ............................... 78
Figure 6.59: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step down test. .......................... 78
Figure 6.60: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection up test.... 79
Figure 6.61: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection down test.
........................................................................................................................................................... 79
Figure 6.62: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step up test after fine tune. ........ 80
Figure 6.63: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step down test after fine tune. ... 80
Figure 6.64: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection up test after
fine tuning. ......................................................................................................................................... 81
Figure 6.65: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection down test
after fine tuning. ................................................................................................................................ 81

List of Tables
Table 4.1: Rules that encapsulate the HO's behaviour in the HOBIC. ....................................................... 18
Table 4.2: Fuzzy-HOBIC rules definition. ................................................................................................. 25
Table 5.1: Mapping of the 14 Fuzzy-HOBIC parameters into the tags P
1
to P
14
, accordingly. .................. 29
Table 5.2: Hard limits of parameters. ......................................................................................................... 29
Table 5.3: List of the soft limits applied for each parameter, and the number of values they can assume. 30

vi
Abbreviations

HOBIC Human Operator Based Intuitive Controller
Fuzzy-HOBIC Extended version of the HOBIC by applying the Fuzzy Logic approach
HO Human Operator
SP Set-Point
PV Process Variable
T
s
Sampling Period
DCS Distributed Control System
FL Fuzzy Logic
FLC Fuzzy Logic Controller
MF Membership Function
GA Genetic Algorithm
PID Proportional-Integral-Derivative
GUI Graphical User Interface

vii
Acknowledgments

First of all, I would like to thank PETROBRAS SA, the Oil & Gas Company where I work, for
the sponsorship of this Project. Without their support and interest I would not be able to carry
out the present research. Especial thanks for my immediate manager, who has always shown his
worries about the development of his work force and supported the idea of this research from
the very beginning.

My supervisors, Professors Jie Zhang and Ming Tham, were always very helpful. Our long
meetings to discuss about the project findings and next steps to take were extremely effective.
Especial thanks to Professor Ming, who always challenged me with his useful observations and
questions about the research.

I would like also to thank two of my professors from Universidade Federal do Rio de Janeiro
(UFRJ), the University where I graduated, in Brazil. Professors Fernando Gil Vianna Resende Jr
and Luiz Wagner Pereira Biscainho are my example of Researchers and one of the reasons that
kept me interested in the academic field.

Thanks to my Brazilian friends that kept in touch with me during all this time I am in the UK.
They are friends forever. I know that I can count on them whenever I need. They know that
when they need I am always there. To my new friends that I met in the UK, I would like also to
say thanks for all the moments we have shared together while taking part of this MSc
Programme in Newcastle. I will never forget them.

Finally, I would like not only to thank, but also to dedicate this work to my family: my father,
my mother, my brother, my grand-mother and my Love. They supported the idea of this project
from the first time I have mentioned it. During these hard work times here in the UK, we kept
daily contact though conference calls that were my main source of energy to keep on going and
studying hard. Being far from them all this time I think was the greatest challenge I faced here
in the UK. I would like to thank you all for the support you gave me all this time. Especial
thanks to my mother for the help to organise the format of the References of this work. To my
Love, which is my best friend as well, I would like to say an additional BIG THANK YOU for
all the LOVE and care we have been giving to each other since the first time we met.

viii
Contents:

Chapter 1: Introduction .......................................................................................................................... 1
1.1 Background ............................................................................................................................... 1
1.2 Motivation of the Research ....................................................................................................... 1
1.3 Project Objectives...................................................................................................................... 2
1.4 Dissertation Overview............................................................................................................... 2
Chapter 2: Literature Review................................................................................................................. 3
2.1 Control loops performance surveys and Product Requirements in the Process Industry ......... 3
2.2 Previous works about controller design obtained through Human Operator actions................. 3
Chapter 3: Human Operator Based Intuitive Controller (HOBIC) Development and Overview........ 7
3.1 Human Operator tasks and responsibilities ............................................................................... 7
3.2 Human Operators behaviour model ......................................................................................... 8
3.3 Encapsulating the HOs behaviour model The HOBIC........................................................ 12
Chapter 4: The HOBIC and Its Natural Extension - The Fuzzy-HOBIC............................................. 13
4.1 The HOBIC - Overview.......................................................................................................... 13
4.2 Defining the HOBICs variables and thresholds ..................................................................... 13
4.3 Determining the HOBICs rules.............................................................................................. 16
4.4 The HOBIC operation description........................................................................................... 20
4.5 The HOBIC natural extension by applying the Fuzzy Logic theory ....................................... 21
4.6 The Fuzzy-HOBIC Summary............................................................................................... 27
Chapter 5: Applying a Genetic Algorithms Approach to Tune the Developed Fuzzy-HOBIC............ 29
5.1 Tuning the Fuzzy-HOBIC - Overview.................................................................................... 29
5.2 Genetic Algorithm terms and definitions ................................................................................ 31
5.3 GA Objective Function definition........................................................................................... 34
5.4 Implemented GA general description...................................................................................... 35
5.5 The implemented GA particular aspects ................................................................................. 37
Chapter 6: Results and Discussion ....................................................................................................... 40
6.1 A Practical Process Control Application................................................................................. 40
6.2 System Simulation with Graphical User Interface .................................................................. 41
6.3 Manual Operations Generation................................................................................................ 46
6.4 GA tuning and the Fuzzy-HOBICs Performance Results ...................................................... 50
6.5 The HOBICs Performance Results ........................................................................................ 76
6.6 Some Practical Application Issues .......................................................................................... 82
Chapter 7: Conclusions ........................................................................................................................ 83
Chapter 8: Recommendations for future work ..................................................................................... 84
REFERENCES:.......................................................................................................................................... 85
APPENDIX: ............................................................................................................................................... 87

1
Chapter 1: Introduction
1.1 Background
Process Control theory has been well explored over decades to, at first, automate the manual
control loops and thereafter, to maintain and improve them. However, it is observed that there is
a gap between the Industry and the state of the art theory [1]. Industry presents, very often, a
high resistance to put into practice what was recently developed. As a result, the vast majority of
the control loops observed operates using traditional PID (Proportional-Integral-Derivative)
controllers. Such kinds of controllers are very simple to apply and understand, when compared
to other more advanced approaches.

However, recent studies have revealed that a great part of those PID control loops are having a
poor behaviour or are operating in manual [1]. This leads to the challenge of investigating those
control loops to verify if they can be improved by simply reviewing the applied PID strategies
or, in some cases, by studying the applicability of new techniques. Nevertheless, being aware of
Industrys inertia to new developments, the challenge is even greater: to develop a control
strategy with a great practical appeal, so it can be easy to understand and apply.
1.2 Motivation of the Research
The present research aims to give a contribution to the Process Control field, developing a
control strategy that intends to combine simplicity with practical appeal, offering another
automatic control alternative to the industrial world.

In the authors experience, very often, newly developed control strategies are difficult to
understand by the operators, the end users of the controllers. Hence, at the first indication of bad
behaviour of the loop, the operators simply switch the controller to manual and if the process
engineer does not verify what caused the problem, the operator normally will not turn it into
automatic again. This will reinforce the statistics of loops in manual in Industry and quickly put
the new technology into disrepute.

This project has the objective of developing a technique which is easily understandable by the
operators. By doing so, the end users of the control loop will tend to support the idea and
maintain the controller in automatic.

2
One way of getting support of the operators is to make the control loop behave as if the loop is
in manual. In other words, the controller has to give actions to the final control element in the
same way as the operator would do, if he was controlling the loop. If the new controller
manages to mimic this behaviour, it is less likely that the operator will switch the controller to
manual.

Therefore, the aim of the present research is to develop a control scheme that can be recognised
by the operator as a manual operation of a given loop. Trying to emulate the operators actions
in a control scheme is, however, not something new as the Literature Review will show.
Nevertheless, there is a lack of real applications of such control technique in the Process Control
field. Hence, some related issues when applying this manual like controller in a real
application are also commented in the present project.
1.3 Project Objectives
Summarising what is described in the previous Section, the objectives of this research are:
To develop a control scheme that is based on the way the Human Operator (HO) acts in
a given Process Control loop
Perform an automatic tuning of the developed control scheme
Compare the generated automatic operations with the manual ones and investigate how
similar they are
To consider some implementation issues when applying the developed control scheme
in a real process control application
1.4 Dissertation Overview
This dissertation is organised as follows. Chapter 2 presents the Literature Review carried out
for this research. Chapter 3 gives a general idea of the desired behaviour of the developed
controller based on a hypothetic model for the way the HO acts in a manual control loop. In
Chapter 4, the controller is formally presented and its natural extension via the Fuzzy Logic
(FL) approach is achieved. However, to cope with the disadvantage of having many parameters
to choose when configuring a Fuzzy Logic Controller (FLC), a Genetic Algorithm (GA) is used
to select the appropriate FLC parameters, and this is described in Chapter 5. A nonlinear
Process Control application is tested with the developed FLC to compare the generated control
actions with the manual operation in Chapter 6, where the results of the system simulation and
discussion are presented. Chapter 7 summarises the conclusions of this work while
recommendations for continuing this research are given in Chapter 8.
3
Chapter 2: Literature Review
2.1 Control loops performance surveys and Product Requirements in the
Process Industry
In 2000, a survey published by Honeywell revealed that 97% of the regulatory controllers from
over 11,000 control loops of refining, chemicals, pulp and paper industries use the PID strategy
[1]. Furthermore, this work mentions that only one third of these controllers provide an
acceptable performance. It also commented that this fact is in accordance with the work of
Bialkoski, published seven years before, in 1993 [2].

The review [1] also explicitly shows that 36% of the analysed PID loops are operating in
manual for at least 30% of the observed data (5,000 samples at the dominant system time
constant). Hence, from the total amount of analysed loops, almost 4,000 controllers have been
switched to manual for a considerable amount of time.

Another survey reported in [1] was about the Product Requirements that Honeywells customers
(managers, control engineers and instrument technicians) had for the past and demand for the
present and future, concerning the controllers in continuous process industry facilities. The
result of the research indicated that the most important requirements highlighted were:
a) Make the technology simple and easy to use;
b) It has to permit the user to find the information quickly and easily;
c) It has to be simple to setup and maintain.

Considering these requirements, one could understand why there is a great inertia to applying
new technologies in Industry. Therefore, an approach that combines practical appeal with
facility to apply could have a good penetration in this world, although, as already said before,
this is a quite challenging issue.

2.2 Previous works about controller design obtained through Human Operator
actions
The study of how to model mathematically the behaviour of the Human Operator for control
design is not a new subject. In 1966, a bibliography of more than 200 works related to
modelling the HO in an automatic control loop was organised in a single paper [3].

4
The great majority of the research on HO modelling in the past was for application in
mechanical systems, such as aircrafts and vehicles dynamics [4], [5]. Investigating more recent
papers in this field, it can be noticed that this area of modelling the human behaviour for
applications in control systems still attracts the researchers attention [6], [7], [9].

After the creation of the Fuzzy Sets theory, by L.A. Zadeh [8], a new field called Fuzzy Logic
(FL) was opened. Because of the subjective appeal that FL suggests when representing the
variables and systems, it was much suitable for describing the way the Human Operator acts in a
control loop. Henceforth, several publications applied the FL theory to control systems by
describing the operators manual actions, such as [6] and [7].

The present research aims to construct a control system with direct application in the continuous
Process Control Industry, also by modelling Human Operator actions. However, it is different
from the vast majority of the previous works in this modelling field. Due to the fact that the
system dominant time-constants in the Process Control area is, in general, greater than in the
mechanical systems, the concern about the HOs reaction time becomes negligible. Hence, the
HO modelling techniques applied in [4] and [5] are not suitable for sluggish Process Control
applications. In these works, the human actions were modelled considering limitations such as
human reaction time-delay (0.15 to 0.25 s) and neuromuscular time-constant (0.1 to 0.6 s).
These are limitations that can be neglected when the involved system dominant time-constants
are much higher (~10s or greater). In the same manner, [6] presented a mechanical application
where the system time-constant had the same order of magnitude of the HO responses. As a
result, an ARMA (autoregressive with moving average) model for the HO had to be identified to
smooth the operator actions, considered to be noisy and less consistent than the ARMA model
ones.

Another important issue to be discussed is the implementation strategy that the recent works [6],
[7], [9] used to model the HO control actions. They applied a model-free type technique. In
other words, the model was extracted based upon input-output data, by using Neural Networks
approach [9]; Neuro-Fuzzy techniques [7] or simply by implementing Fuzzy rules directly [6].
Hence, although the model-free approach is able to approximate the HO behaviour, as the
results of these works show, it fails to present a clear and easily understandable description of
how the HO behaves and which rule system it uses to generate the actions. Even when applying
the FL technique directly, as done in [6], the model-free approach in this case generated a set of
15625 rules, which is quite difficult to understand and maintain in a practical application.

5

Figure 2.1: Fictitious representation of a Manual control signal compared with a generated control signal
using a model-free approach.

In the present project, a model-based approach is applied using the FL theory. Hence, the
number of generated Fuzzy rules is expected to be much less than that in [6], and therefore
easier to understand and apply in the Process Industry.

The work developed in [9] is of particular interest because it was related specifically to Process
Control. The application presented was the control of the level in a tank, which has a nonlinear
behaviour since the output flow is proportional to the square root of the level. This paper shows
that the manual operation can be approximated using a Neural Networks approach. However,
the generated control signal is continuous, compared with a stair-like manual signal. Thus, it
is not likely that an operator would recognise such kind of control signal as a manual one.
Figure 2.1 illustrates a fictitious example of a manual operation signal and that generated by the
applied model-free approach. The difference in the signals nature is clear. Model-free
approaches tend to generate continuous signals when modelling the operator, since there is no
restriction to how the signal has to be generated. The algorithm simply tries to minimise a
certain optimization criteria, such as the sum of squared errors between the desired system
response and the one generated by the model, as implemented in [9].

On the other hand, a FL model-based approach would be able to produce a stair-like signal, if
the proposed rules that comprise the Human Operator model are designed to perform this task.
Hence, the generated control actions look like Human Operator ones and because they tend to
understand and feel more comfortable with these signals, the HO tend not to switch the
6
controller into manual. Nevertheless, one disadvantage of the FL model-based system is that the
resultant Fuzzy Logic Controller (FLC) will need to have its parameters adjusted so it will be
able to reflect the behaviour of a given operator. The adjustment of these parameters may be a
tedious task, considering that each linguistic variable of the FLC can be composed of several
Membership Functions (MFs). Thus, these MFs have to be appropriately adjusted so that the
generated control signal approximates the HO behaviour. This will happen if the model chosen
to describe the HO control actions is a suitable one. For readers who are not familiar with the
FL concepts, refer to [10].

One way to cope with the mentioned disadvantage of the model-based FL approach is to come
up with an automatic procedure for finding the appropriate adjustments of the MFs. In this
work, this procedure is called tuning. As there are many possible combinations for the MFs
parameters, the search space for the tuning procedure is inevitably large. In these cases of large
search spaces, finding the optimal solution tend to be prohibitive in terms of computational
effort. To solve such kind of high dimensional search space problems, Genetic Algorithms can
be applied [11]. These algorithms are based on Evolution Theory to search for a suitable
solution of a given problem. Biological operators such as crossover and mutation are
implemented to produce offspring from a population that evolves based on the natural selection
of the most well adapted individuals from each generation of potential solutions.

In this work, a Genetic Algorithm (GA) was developed to search for a set of suitable tuning
parameters for the MFs such that the generated control signal matches the HO manual signal.
This GA is then used to tune and validate the proposed FL model. If the GA is not able to find a
suitable tuning for the MFs then it is not possible to affirm that the developed model is
applicable to represent the HO actions for the specific application where it is intended to apply
the developed controller.

Summarising, this project focuses on the creation of a human model based controller that is easy
to understand and apply using FL techniques. A GA was used to tune and validate the model in
a given nonlinear application. The following Chapter highlights the principles used to develop
this control system, called Human Operator Based Intuitive Controller (HOBIC).
7
Chapter 3: Human Operator Based Intuitive
Controller (HOBIC) Development and Overview
3.1 Human Operator tasks and responsibilities
To be able to establish a hypothetic model for operator behaviour when controlling a manual
loop, it is important to understand his tasks and responsibilities. In a process plant, the HO has
the responsibility of maintaining the plant under control, mainly by manipulating the final
control elements, in manual loops, or by changing the controllers set-point (SP) values.

The first concern of the operators is about safety. This is a reflection the Companies concern
about Health & Safety issues. Common questions that they face on a daily basis are: are the
process variables (PVs) within its constraint limits? Has the alarm system identified any process
upset? Where is the process upset?

Right after the security concern is the production task. The production throughput should not
decrease in time. Supervisors are always checking for production problems and possible causes
of such incidents.

Hence, whenever a new control system is implemented or updated in Industry, this affects
directly the work of the operators. The system is normally implemented and installed by the
Process Control engineer, who has to negotiate with the operators a specific date and time to test
the controller. After the commissioning period, if the performance of the controller is acceptable
it remains in automatic and it starts to be observed by the operators as one more task. In the
authors experience, very often, because of a change in the operating conditions or plant
nonlinearity for example, a change in the controller performance may lead the operators to
switch an automatic control loop to manual. This is the controller mode that they are more
comfortable with in case of a possible process upset. If this situation cannot be investigated by
the Process Control engineer, who might be involved in many other projects and tasks, the loop
is likely to remain in manual.

One way of discouraging the operators from switching the control system to manual is to
familiarise them with the applied controller. A control system that operates as if the loop was in
manual can be a step towards achieving this objective. Therefore, the next Section is dedicated
to describing how an operator behaves when operating a control loop in manual.
8
3.2 Human Operators behaviour model
After understanding the operators tasks and responsibilities in a process plant, it is possible to
establish a hypothetical model to describe how the HO would behave when controlling a manual
loop. Two modes of operation may be defined for the HO:

A. When changing the operating conditions (SP-Tracking);
B. When rejecting disturbances (Disturbance Rejection).

In the first mode of operation (Mode A), the operator, to not disturb the system, will change the
operating conditions only when necessary by slow changes in the final control element. This
tends to minimise some problems such as interactions between loops, for example. Hence, the
process variable (PV) will be carefully taken to the desired new operational point. This manual
procedure is equivalent to changing the controller SP, when it is in automatic. Hence, Mode A is
called SP-Tracking mode of operation.

In Mode B, to reject a given disturbance, the behaviour of the operator is normally more
aggressive. This is natural, since his task is to maintain the process plant under control. Then, if
an undesired disturbance is affecting a given PV, the operator will have to take the right action
to bring the PV back to its desired value in a sufficiently fast way.

An intuitive algorithm to describe the way the operator adjusts the final control element
(Control Valve, for example), considering a single variable system, can be itemised as follows:
1) Is the PV following the desired path (SP)?
If Yes then Do nothing. The process is under control
Else
Is the mode of operation Mode A or Mode B?
If Mode A:
- Start actions to push the PV into the desired SP
- Apply slow actions to try to not disturb the Plant or other processes
involved
Else
- Start actions to take the PV back to the original SP
- Apply more aggressive actions depending on the PV values and its
trend
End
End
9
2) When in Mode A:
Manipulate the Control Valve appropriately and wait for the system to react
If the trend of the PV is already going to the desired SP with an appropriate velocity
do not change the Control Valve value
If the PV trend is going too fast to the desired SP, change the Control Valve value to
slow down the PV behaviour and wait for the system to respond
If the trend is going too slow to the desired SP, change the Control Valve value and
wait for the system to respond

3) When in Mode B:
Perform the same actions done in Mode A, but with more aggressiveness.
The degree of aggressiveness depends upon the value of the PV. If it is far from the
desired value and going away faster, the action will be more aggressive.

Items 1, 2 and 3 describe roughly an intuitive hypothetic model of the operator behaviour when
controlling a single input, single output system, subject to disturbances. However, this
behaviour can be more detailed if one considers Figure 3.1 and Figure 3.2.

From these Figures, some subjective terms mentioned in items 1, 2 and 3 such as velocity,
slow and fast, are clarified. It can be observed that as the operator inspects the PV (in
general, this is a signal with associated noise), he determines if the PV is under control by
observing three variables, mainly:

1) Variable 1 Angle that the PV trend makes with respect to the desired SP;
2) Variable 2 Distance between the PV and SP;
3) Variable 3 The direction of error: increasing or decreasing?

Hence, the action taken in the Control Valve will be generated after analysing these three
variables. Following the action, the operator has to wait some time until the system reacts to it.
The minimum time to wait (
wait
t ) should be greater than the Process time-delay, supposed to
be known by the operator. Thus, after observing the result of his action, the HO judges again the
variables 1, 2 and 3 and takes another action or waits, if the PV is already under control again or
if the PV trend is behaving as intended. The actions taken can be: increase, decrease or no
action. The term increase is used whenever the control actions are made to increase the
absolute value of Variable 1. The term decrease is exactly the opposite. The term wait
means that the operation will not make any adjustments.
10

Figure 3.1: Intuitive HO behaviour when in Mode A of operation.

Figure 3.2: Intuitive HO behaviour when in Mode B of operation.
11
The PV is considered to be behaving as intended if it is approaching the SP within a given
range of angles (velocity) at a given distance from the SP that the operator establishes in his
mind for that specific system. Therefore, if the angle is not within the desired range of values
for a specific distance away from SP, then the control action is increased or reduced
appropriately. The amount of action in the Control Valve will depend on the Mode of operation
and on variables 1, 2 and 3. From Figure 3.1 and Figure 3.2 it is clear that for SP-tracking
(Mode A) the actions are less aggressive than when rejecting disturbances (Mode B). These
figures also show that the HO has, in his mind imaginary thresholds to determine how far from
the SP the PV is (Variable 2). These limits are highlighted in the figures as: Control Thresholds
(CTRL_TSH) and Distant Thresholds (DST_TSH). Although not illustrated in the Figures, the
operator is also aware of the desired range of angles the PV should establish with the SP
(Variable 1) considering variables 2 and 3.

For example, referring to Figure 3.1, when a change in the SP is desired, the operator knows
where the new desired SP value is supposed to be. Thus, he verifies that the angle the PV is
making with the SP (
0
) is small since he wants to achieve a new SP value. Then, a control
action is made to establish a greater angle (
1
). After observing the system response and
verifying that the angle between PV and the SP is still small, he increases the control action
once more. Thus another angle is established (
2
) during the observation time period (
2
wait
t ).
At the end of this second observation time period, the PV is already reaching the SP. As the
operator is aware of this, he realises that the angle between the PV and SP is big, so he
decreases the control action, generating a new angle (
3
) during
3
wait
t . Finally, after this third
observation time period, the Control Threshold is achieved and because the angle
3
is too
big for that region, the last control action reduction is made. As the established angle
4
is
considered acceptable for the Control Threshold region, the system is then considered under
control again and no action is taken.

The same reasoning can be used to describe the operator actions in the case of a disturbance
occurring in the system (Figure 3.2). Since there is no SP change, when the Control Threshold is
violated this means that some disturbance is present and it needs to be compensated by the HOs
action in the Control Valve. The operator observes the angle that the PV is making with the SP
(
0
) and take the first action. After waiting for the system to respond to this change (
1
wait
t ),
he observes that the angle has increased (
1
) and the error between SP and PV is also
increasing. This causes him to decrease the control action. After waiting for the PV to react to
this other change, the operator notes that although the angle between PV and SP is now small
12
(
2
) the PV is still far from the Control region. Hence, an increase action is taken. At last, after
3
wait
t , the operator realises that the established angle
3
is too big for the Control region. He
then decreases the control action, leading the PV to an acceptable angle for the Control region
(
4
). Therefore, the system is considered to be under control again and no further action is
taken. It is important emphasize here the meaning of the terms increase and decrease
(reduce), for the control action. These terms are directly related to Variable 1 values. In other
words, if the HO intends to increase the angles, an increase action is taken, and vice-versa.

It is also worth noting that although the PV used to illustrate the HOs control actions is shown
as a continuous signal in the figures, in a practical application this signal is constructed by
sampling the PV. Its value is then displayed by the Distributed Control System (DCS) software
in the Control Room, where the operator is often situated observing the PV trend. So, the time
period that the operator has to wait between the actions is taken as a number of samples, that
should be greater than the system time-delay, as already stated.

Although not clearly shown in Figure 3.1 and Figure 3.2, the time that the operator has to wait
for another action (
wait
t ) will depend on the amount of increase or decrease action imposed to
the Control Valve. The larger the control action the greater is the
wait
t value. The larger the
action the greater is the effect in the PV. Waiting longer will give time for the system to change
the actual behaviour and avoid a new large control action to be taken. When there is no action in
the Valve, the operator is considered to be in an alert position, for the sake of this developed
hypothetical human operator model. Hence, the time to wait in this case is zero, since no action
was taken or the last action taken resulted in the system being considered to be under control.
3.3 Encapsulating the HOs behaviour model The HOBIC
By describing the operators way of controlling a given PV, the hypothetic model of how the
HO manipulates the Control Valve to control the correspondent PV is formulated. Since the
algorithm described is based on an intuitive way the operator thinks and then acts in the Control
Valve, the controller that is able to encapsulate this behaviour is going to be called Human
Operator Based Intuitive Controller, denoted by HOBIC, henceforth.

The next Chapter focus on the HOBIC implementation, which is based on rules that analyse
Variables 1, 2 and 3, and give the correspondent actions to the Control Valve, waiting for the
next action to take place. Also in this Chapter the natural extension of the HOBIC, based on the
Fuzzy Logic theory is presented as well, leading to the Fuzzy-HOBIC.
13
Chapter 4: The HOBIC and Its Natural Extension -
The Fuzzy-HOBIC
4.1 The HOBIC - Overview
In Chapter 3, an intuitive hypothesis for the HOs behaviour when controlling a loop was
established. This Chapter describes the implementation of the controller that encapsulates the
operators behaviour, the HOBIC, and its extension, the Fuzzy-HOBIC.

Basically, by observing the operators behaviour under both SP tracking and disturbance
rejection conditions, three variables were highlighted as the ones the HO analyses before taking
the control actions. Hence, the HOBIC has to consider these variables in the same way the
operator does and then take the appropriate control action. The next section shows how these
variables are mathematically defined, as well as the Control and Distant Thresholds
(CTRL_TSH and DST_TSH), described in the previous Chapter.
4.2 Defining the HOBICs variables and thresholds
According to the established hypothesis of the HOs behaviour when controlling a loop in
manual, the variables he observes are, as defined in Chapter 3:

1) Variable 1 The angle that the PV trend makes with respect to the desired SP;
2) Variable 2 The distance between the PV and SP;
3) Variable 3 The direction of error: increasing or decreasing?

To define mathematically these variables, one can refer to Figure 4.1. This Figure suggests the
way each of these variables is obtained. Starting with Variable 3, denoted as ErrorSignal (ES), it
is possible to make this variable reflect whether the error between SP and PV is increasing or
decreasing. If the error is increasing, the number +1 is assigned to ES. On the other hand, for
decreasing errors, when the PV is tending to approach the SP, this variable receives the value
-1. Figure 4.1(c) illustrates a situation where the actual PV value, represented by PV
act
, is
tending towards increasing the error between SP and PV. Hence ES equals +1, as indicated.

Regarding Variable 2, Figure 4.1(b) shows that this variable can be defined by the absolute
value of the error percentage between PV
act
and SP, i.e. ErrorPercentage (EP). The reason for
defining the distance between PV and SP as an error percentage measure is because the operator
tends to analyse the PV value relatively to its desired value to judge if the PV is close or far
14
from the SP. For example, for SP values of 100 units, deviations of 3 units can be considered to
be small (3%) by the operator, and no action would be taken. If the SP is 1, however, a
change in the desired value of 3 units is considered to be a big change and will signal that the
process needs a corrective action. It is worth noting that if the SP is zero, the EP will be
undefined. In this case, EP is defined as the absolute value of the PV times 100% (EP =
abs(PV
act
)*100).

(a)

(b)

(c)
Figure 4.1: Variables used to encapsulate the HO's behaviour in the HOBIC.
Variable 1 defines the angle that the PV trend makes with the SP, denoted by Slope (S) in
Figure 4.1(a). In Chapter 3, when describing the way the operator manually controls a loop, it
was stated that he identifies these angles even in the presence of noise. The human being has a
great ability of quickly identifying patterns in graphs. If one is asked to draw a line that would
describe the behaviour of the PV in one of the graphs shown in Figure 4.1 it is likely that the
result would be very similar to the one shown in Figure 4.1(a). This line can be obtained
numerically using Multi-variable Least Squares (LS) [12]. Equation (1) shows how the PV trend
can be represented as a straight line approximation, where t is the current time instant
(obtained at sample n); b and s are the bias factor and the slope, respectively. T
s
is the
sampling period.
b ) (nT s b s.t PV
s n
+ = + = (1)
15
The Multi-variable LS method determines the best (b, s) values that minimises the error ( )
between the predicted PVs, obtained from Equation (1) and the real PV values, from the PV
trend. This minimisation problem can be described by Equation (2), where PV
n-i
denotes the
previous PV samples that make up the PV
real
vector. PV
pred
is the vector of predicted PV values,
obtained from (1), for each sample.

{
s
b
.
nT 1
1)T - (n 1
2)T - (n 1
3)T - (n 1
4)T - (n 1
PV
PV
PV
PV
PV
PV PV
X
s
s
s
s
s
act
1 n
2 n
3 n
4 n
pred real
+
(
(
(
(
(
(
(
=
(
(
(
(
(
(
+ =
4 43 4 42 1
(2)
Following the Multi-variable LS approach, it is easy to show that the optimum value for (b, s) is
given by Equation (3) [12].

T
real
T 1 T
PV X X) (X

= (3)

Hence, after obtaining , the slope s is the second element of this vector. Thus, to obtain the
angle in degrees (S) that the PV makes with the horizontal line (SP), Equation (4) is applied.
The reason for storing the angle in degrees is because it facilitates understanding of the
behaviour of the HOBIC. The bias term is not used.

180
* (2)) atan( S = (4)

From Equation (2), one can notice that the angle is obtained using five samples (PV
act
and the
past four samples). If fewer samples are used, then the Slope detection method is more sensitive
to the presence of noise in the PV. On the other hand, when using more samples to obtain the
slope, the result might not reflect the current PV trend, being overly influenced by its past
behaviour. Hence, a total of five samples are used to detect the Slope. It is being assumed that
the sampling period used is sufficiently low to capture the system dynamics (eg.: 10% of the
dominant time-constant) and sufficiently high to not to capture only the noise dynamics.

After defining how the variables 1, 2 and 3 are determined in the HOBIC, the next step is to
specify the thresholds CTRL_TSH and DST_TSH. These limits could be obtained by
investigating the HOs actions when manually operating the control loop. The Control
Threshold is, by definition, the limits within which the operator judges that the system is under
16
control and no action is taken, when the PV has small Slope values. On the other hand, the
Distant Threshold is obtained by determining the distance between PV and SP, when the
operators actions start to increase significantly. Preliminary observations of the HOs behaviour
indicate that typical values for CTRL_TSH are between 1 and 3%, while DST_TSH is between
5 and 12%, although these values can be different in different applications.

Another method that can be used to obtain these limits is by interviewing the operator of a
particular control loop. An automatic method of detecting these thresholds will be presented
later in Chapter 5, because the other two mentioned methods are quite subjective, since the
operator might not be able to explain when exactly he changes his actions, or it might be
difficult to identify from which point the HOs actions start to increase significantly.
4.3 Determining the HOBICs rules
After defining the HOBICs variables and thresholds, the next step is to determine the HOBICs
rules. In other words, the way that the operator behaves is encapsulated in these rules by
observing the variables already specified in the previous Section.

In Chapter 3, it was stated that the HO compares the observed angles (S) that the PV makes with
the SP with a range of angles that he has in his mind and judges if the angle is small,
adequate or big, depending on how far the PV is from the SP. If the angle is considered to
be adequate no action is taken. Otherwise, the control action is increased or decreased
appropriately. Again, an increase action is an action that increases the absolute value of S, since
the values of S lie in the interval [-90
o
, 90
o
]. The opposite is a decrease action. The operator then
has to wait for the system to react before another decision is made. This period of inaction has
to do with the systems time-delay, which the operator is aware of.

Therefore, to be able to embed in the HOBIC the rules that the operator is using, four angle
limits are defined:
L0
,
L1
,
L2
,
L3
. The first angle limit (
L0
) is a dead band limit. In other
words, the HOBIC will consider that the Slope is zero if S is less than
L0
. The other three limits
are distributed from
L0
to 90 degrees, dividing this region into intervals. These limits and their
associated tags are described in Figure 4.2. For each region of Slope values and considering the
EP and ES variables, a specific action is taken in the Control Valve. Judgment about what action
is to be taken given the system state (S, EP, ES) is performed by a set of rules.

17

Figure 4.2: Limits and their tags established for the Slope (S) between the PV trend and SP.

Figure 4.3: Division of the output delta control signal into defined intervals.
Before presenting the rules, it has to be clear that the control action to be taken is an increase,
decrease or no action. The amount of increase of decrease, so called deltaAction, is obtained by
dividing the range of values that the operator would possibly apply, into intervals. A tag:
small, medium and big is attributed to each of these intervals, as can be seen in Figure
4.3. Hence, when applying the rules, these tags can be used, as well as the tags for the S limits
(Figure 4.2). Translation of the deltaAction tags into values is performed by linear functions that
depends upon the (S, EP, ES) values, as will be demonstrated later. The set of rules is described
in Table 4.1.

It is important to notice that the control action is shown in the Table as an absolute value.
Whether it is an increase or decrease action, in other words, the sign of deltaAction, is
determined by observing the ES value. In general, if ES is -1 (error decreasing) the action is an
increase, unless when close to the SP (within the Distant threshold). Otherwise, a decrease
action will be taken to reduce S. An exception to this general rule comes when the value of S is
within the dead band limit (S_ZERO). In this case, an increase action will always be taken.
Since the values of S in these limits are considered negligible, it is not possible to determine if
the error is increasing or decreasing, due to noise. The error is considered to be in a steady state.
Hence, the HO will try to speed up the velocity that the PV is reaching the SP, giving an
increase action regardless of the distance from the SP.
18
Table 4.1: Rules that encapsulate the HO's behaviour in the HOBIC.
Rule N
o
Rule Definition abs(deltaAction)
1 IF (S_ZERO) and (EP <= CTRL_TSH) zero
2 IF (S_ZERO) and (CTRL_TSH < EP <= DST_TSH) small
3 IF (S_ZERO) and (EP > DST_TSH) medium
4 IF (S_L0_L1) and (EP <= CTRL_TSH) small
5 IF (S_L0_L1) and (CTRL_TSH < EP <= DST_TSH) small
6 IF (S_L0_L1) and (EP > DST_TSH) medium
8 IF (S_L1_L2) and (CTRL_TSH < EP <= DST_TSH) and (ES = -1) zero
9 IF (S_L1_L2) and (CTRL_TSH < EP <= DST_TSH) and (ES = +1) medium
10 IF (S_L1_L2) and (EP > DST_TSH) and (ES = -1) small
11 IF (S_L1_L2) and (EP > DST_TSH) and (ES = +1) medium
13 IF (S_L2_L3) and (CTRL_TSH < EP <= DST_TSH) and (ES = -1) small
14 IF (S_L2_L3) and (CTRL_TSH < EP <= DST_TSH) and (ES = +1) medium
15 IF (S_L2_L3) and (EP > DST_TSH) and (ES = -1) zero
16 IF (S_L2_L3) and (EP > DST_TSH) and (ES = +1) big
17 IF (S_L3_+) and (EP <= CTRL_TSH) medium
18 IF (S_L3_+) and (CTRL_TSH < EP <= DST_TSH) medium
19 IF (S_L3_+) and (EP > DST_TSH) and (ES = -1) small
20 IF (S_L3_+) and (EP > DST_TSH) and (ES = +1) big

Another remark that can be made about Table 4.1 is that the rules that do not generate any
action (deltaAction = zero) reflects the HOs feeling that the specific angle between the PV
trend and SP is adequate, considering the distance from the SP (EP) and if the error is increasing
or decreasing (ES). Rules 1, 8 and 15 represent this HOs behaviour.

These 20 rules that describe the way the HOBIC will generate the deltaAction values are
divided into five blocks, as can be observed from Table 4.1. These blocks are indicative of the
Slope Limits being considered (S_ZERO, S_L0_L1, S_L1_L2, S_L2_L3 and S_L3_+) and
facilitate the overall understanding of the described rules.

When applying the rules in the HOBIC, after determining whether the deltaAction is zero,
small, medium or big, a translation of these tags to a numeric value has to be made. To
perform this task, linear functions are applied in the range of each tag, resulting in a deltaAction
that is proportional to the Slope of the PV trend, as Figure 4.4 illustrates.
19

Figure 4.4: How the deltaAction tags are translated into control actions.

For example, when applying rule number 11 (R11), the observed PV is making an angle with
the SP that is within the range S_L1_L2. EP is greater than DST_TSH and the error is
increasing (ES is +1). The resultant deltaAction (medium) is computed by Equation (5).

2
L1 L2
L1
2 3
D

S
). D (D n deltaActio +
= (5)

This Equation shows that bigger angles (S) will give greater actions within the established
range. Note that if S equals
L2
(the maximum value of S within the range S_L1_L2),
deltaAction equals D
3
, which is the maximum value within its range (D
2
-D
3
). Furthermore,
minimum deltaAction of the range (D
2
) occurs when S equals
L1
. Similar equations are
achieved when the S values lie in the other angle limits (S_ZERO, S_L0_L1, S_L2_L3 and
S_L3_+). The general form of Equation (5) can be seen in (Figure 4.4).

20

Figure 4.5: Example of the HOBIC operation in a hypothetic control loop.

4.4 The HOBIC operation description
After defining the HOBICs variables and rules to reflect the operators behaviour, it is
important to summarise how the HOBIC would operate in a control loop. Figure 4.5 illustrates
how the HOBIC would maintain a given PV under control, after a disturbance has occurred.

On the left hand side of the Figure, it is possible to see the behaviour of the PV and the
corresponding control actions as a function of time. On the right hand side of the same Figure, a
block diagram is used to express how the HOBIC would maintain this PV under control. The
first block of this scheme is the PV Trend. This block takes the actual PV value (PV
act
) and
the past 4 samples, to obtain the HOBIC variables (S, EP, ES), as already discussed in Section
4.2. With these variables, the HOBIC rules can be applied, choosing which rule is going to be
activated to generate the deltaAction. After choosing the rule, the translation of the tag for the
deltaAction into a value is made (Figure 4.4). Finally, the deltaAction is given to the Control
Valve as an increase, decrease, or no action with reference to its current value. Equation (6)
quantifies this procedure, where it is noticed that the adjustment to the valve is clearly
incremental. In other words, it is a delta action, in percentage of opening/closing the Control
Valve.
21
n(%) deltaActio ion(%) rlValveAct PreviousCt u + = (6)

After making the control action, the controller has to wait for the system to respond, if the
deltaAction is different from zero. The time to wait (
wait
t ) will be a number of samples that
has to be greater than the process time-delay. This time will be greater or shorter depending on
the magnitude of deltaAction. Higher values will give greater periods of time to wait, while low
values will make the time to wait shorter, as already stated in Chapter 3. However, this block
wait will be explored further, in the results chapter (Chapter 6).

From the example shown in Figure 4.5, it is possible to observe that, at the beginning, the
hypothetical system has its PV under control (disregarding the inherent noise), and no
deltaAction is taken. Rule 1 (R1) is being generated by the HOBIC continuously. After a while,
the PV starts to establish an angle different from zero with the SP. Hence, the S value is greater
than the dead band limit (S_ZERO) and Rule 4 (R4) becomes active. At this moment, the
deltaAction is small and the period of time to wait is also generated. The next time the
variables are obtained, Rule 9 (R9) is selected. Then, a medium control action is generated
with a longer period of time to wait for the system to react. The next time the PV trend is
analysed, Rule 5 (R5) is activated, producing a small deltaAction with a period of time to wait
equal to the first one. Finally, after waiting for the system to respond to this action, Rule 1 is
again activated, showing that the PV is under control.

4.5 The HOBIC natural extension by applying the Fuzzy Logic theory
The previous Section described a hypothetical example of how the HOBIC would operate in a
control loop when a disturbance appears in the system. However, before going any further in a
practical implementation of the HOBIC, it is important to note that it is possible to extend the
actual HOBIC configuration to make the control system more flexible, and hence, easier to be
used to approximate the behaviour of a given operator.

In the actual HOBIC configuration, several parameters have to be adjusted/tuned before the
controller can start to operate. These parameters are listed as follows:

Process time-delay: referring to the time the system reacts to a given input;
Control Threshold and Distant Threshold (CTRL_TSH, DST_TSH);
Slope Limits:
L0
,
L1
,
L2
,
L3
;
deltaAction Limits: minDelta and maxDelta.
22
As stated before, one way of defining these parameters would be by visually inspecting past
manual operations of the loop being controlled. Another way would be through interviewing the
operator. However, some of the HOBIC parameters, such as the Slope Limits, can be difficult to
be set accurately by these previous methods, since they are quite subjective. To establish an
objective way of generating suitable parameters, an automatic tuning procedure is described in
Chapter 5.

Although there are several parameters to tune, some questions can arise about the ability of the
current HOBIC configuration to approximate the HOs behaviour. For example: Why divide the
range of deltaAction into equally spaced intervals (small, medium, big)?, or How it is
possible to cope with the operators different behaviour while rejecting disturbances or
performing the SP-Tracking procedure? How can the control action be made less aggressive?

The answer for the first question could be that this is an intuitive approach. However, its results
have to be tested to ensure if it is reasonable. Another approach would be making the small
action limits smaller than the other ones to cope with a less aggressive behaviour, or establish a
new maxDelta. In Chapter 6, when presenting the HOBICs performance, this alternative of
reducing the output range (new maxDelta) is adopted to establish an overall less aggressive
behaviour. Nevertheless, this method can reduce the controllability range of the PV in the loop.

The approach of changing the output limits would create more parameters to be tuned and could
make the tuning procedure more difficult, without improving the system overall understanding.
Hence, instead of following this method to increase the HOBICs flexibility, an extension of its
configuration is made, based on the fact that the actual controllers settings are close to the
Fuzzy Logic (FL) control approach [10]. The extension of the current controller to a Fuzzy-
HOBIC one, should give the needed flexibility to approximate a given operators controlling
behaviour without requiring much effort to perform the extension. The flexibility gains are
specified after defining the Fuzzy-HOBIC.

Using the FL approach, the actual HOBIC variables S, EP and ES are considered to be linguistic
input variables. The Linguistic values for these variables are as follows:
Slope (S): zero, small, medium, big
ErrorPercentage (EP): small, medium, big
ErrorSignal (ES): positive, negative

The term linguistic is used to indicate that the values defined are not numeric, but fuzzy. They
are described using words (small, medium, big, etc) that define qualitatively, the values
23
these variables will assume, improving the overall understanding of the applied rules. Each
linguistic value is mathematically defined by a function, so called Membership Function (MF).
Readers who are not familiar with the FL theory can refer to the Supplementary Material
provided in [10].

Figure 4.6: Fuzzy-HOBIC Linguistic variables.

These MFs are set by the actual HOBIC parameters to describe the variables S, EP and ES
values. Figure 4.6 illustrates how the MFs of each linguistic variable are configured. From this
Figure, it is possible to notice that, in general, trapezoidal functions are used to define the MFs.
Triangular and trapezoidal functions are usually applied as MFs in Fuzzy Logic Controllers
[10]. In the present work, trapezoidal functions are preferred because they are more general than
the triangular ones. Moreover, trapezoidal MFs can be reduced to triangular ones. For example,
24
the medium MF of Slope can be reduced into triangular if
L2
equals
L3
, as can be seen by
inspecting Figure 4.6. Hence, the use of trapezoidal MFs lead to less loss of generality.

From Figure 4.6, for the Slope input, although the HOBIC Slope Limits are being used to define
the trapezoidal functions, there are still two new parameters to be set (N
1
and N
2
). The same
applies to the ErrorPercentage input, where the parameters N
3
and N
4
are needed to complete
the MFs description. These new parameters have the advantage of offering more flexibility to
the controller to match the operators behaviour. However, the disadvantage is the increase in
the number of parameters to specify.

About the ErrorPercentage input, it is worth noting that the maximum value that it is permitted
to assume is 100%. This means that distances from the SP greater than 100% will always be
considered big. This seems to be a reasonable assumption since 100% means that the PV
value is twice greater than the value it should be. Hence, it is far from the SP.

An important observation about the ErrorSignal (ES) variable is that, although this variable will
be part of the Fuzzy-HOBIC system, strictly speaking, ES is not a fuzzy variable because it
assumes only two values (+1 and -1). Hence, the linguistic variables are denoted as
positive or negative (with no overlap), accordingly. The reason for considering this variable
as a fuzzy one is to facilitate the implementation when applying toolboxes that offer ready to
use Fuzzy packages, such as The MATLAB FL toolbox [13]. Then, as the ES variable takes part
in the fuzzy rules, it has to be considered as a fuzzy variable when applying this toolbox.

After defining the fuzzy input variables it is possible to construct the rules that define the Fuzzy-
HOBIC. These fuzzy rules are described in Table 4.2. Observing and comparing them with the
previous HOBIC rules, it is possible to conclude that they are quite similar. One major
difference that can be noticed is that in the present case, the rules look more similar to the
description of the operators actions, since it uses the linguistic terms to describe the IF-Then
statements. This procedure of mapping the variables values (S, EP, ES) into linguistic values
(small, medium, etc.) is called Fuzzyfication. Another difference is that this set of rules is
less than the previous HOBIC ones: 15 rules are describing the Fuzzy-HOBIC, instead of the
previous 20 rules. This happens without loss of generality because of the advantage that the
fuzzy rules give of activating more than one rule at a time. For example: regarding the Slope
input, if the angle S is in the range
L1
-
L2
it will be considered that the Slope is small and
medium, with the appropriate degrees of membership. Hence, if the EP is less than
CTRL_TSH (small only), and ES is -1 (negative), both rules 4 and 7 would be activated.
25
Table 4.2: Fuzzy-HOBIC rules definition.
Rule N
o
Rule Definition abs(deltaAction)
1 IF (S is zero) and (EP is small) zero
2 IF (S is zero) and (EP is medium) small
3 IF (S is zero) and (EP is big) medium
4 IF (S is small) and (EP is small) small
5 IF (S is small) and (EP is medium) small
6 IF (S is small) and (EP is big) medium
7 IF (S is medium) and (EP is small) small
8 IF (S is medium) and (EP is medium) and (ES is negative) zero
9 IF (S is medium) and (EP is medium) and (ES is positive) medium
10 IF (S is medium) and (EP is big) and (ES is negative) zero
11 IF (S is medium) and (EP is big) and (ES is positive) big
12 IF (S is big) and (EP is small) medium
13 IF (S is big) and (EP is medium) medium
14 IF (S is big) and (EP is big) and (ES is negative) small
15 IF (S is big) and (EP is big) and (ES is positive) max

This flexibility that the fuzzy rules offer of activating more than one rule at a time is an
advantage when describing the operators behaviour, since it can cope with the uncertainty that
exists in the borders of the regions defined by the rules. It is difficult to say exactly where the
Slope goes from small to medium. Hence, a better approach is to combine both rules
proportional to the degree of membership of the given Slope value (S) to each of the fuzzy sets
(small or medium, in this case), which is exactly what the FL Inference System does.

After activating a certain rule or set of rules, the output deltaAction has to be generated. Since
the output of each rule is also a fuzzy set (zero, small, medium, big or max), as
shown in Table 4.2 and Figure 4.8, it has to be translated into a numerical value, in the same
manner as it was performed in the HOBIC (Section 4.3). To perform this task, each rule will
generate a fuzzy set using the minimum (min) implication method. After the implication method,
there are 15 generated fuzzy sets, one as the output of each rule, which are aggregated using the
maximum (max) aggregation method. The final step to generate the deltaAction is to apply the
Defuzzification of this resultant fuzzy set. There are several Defuzzification methods in the
literature, such as centroid, centre-of-sums, height, modified height and centre-of-sets [10].
However, in this work, only the centroid is applied as it is the most commonly used one.
26

Figure 4.7: Fuzzy-HOBIC Inference System general description.

Figure 4.8: Fuzzy-HOBIC output variable description.

Figure 4.7 shows a general description of the Fuzzy-HOBIC Inference System, in the same
manner as the HOBIC was previously described in Section 4.4. However, it is important to
mention that it is not the scope of this work to verify the impact of each of the mentioned
Defuzzification methods, or trying different implication or aggregation methods, since it is
believed that the amount of degrees of freedom that the current controller (Fuzzy-HOBIC)
27
already has is enough for approximating the HOs behaviour. If it is concluded that the applied
Fuzzy configuration does not work then another approach has to be tried.

About Figure 4.8, the linguistic values zero and max are applied to force the
Defuzzification process to give the numeric outputs zero and maxDelta, according to its
respective fuzzy rules. A zero output is already known from the HOBIC rules while the new
limit is maxDelta. This is introduced for security reasons, because if one inspects Table 4.2, he
will find that the only time the output value is max is when S is big and EP is big. In
other words, the PV is moving far from the SP, indicating that the Control Valve needs a severe
action, the highest the operator would normally give (maxDelta) in a single step. It can be also
seen from Figure 4.8 that the small MF has its first two parameters equal to minDelta. This is
done to respect the fact that the minimum action different from zero the HO would give to the
Control Valve is minDelta. The values of minDelta and maxDelta may vary depending upon the
application or the operators attitude when controlling a given loop, as the Figure suggests.

Another remark about the fuzzy output deltaAction is that now it is possible to establish new
boundaries for the small, medium and big linguistic values by varying the parameters N
5
-
N
8
. In the HOBIC, the intervals were equally spaced. This is one more source of flexibility that
can be used to produce more aggressive behaviour, when tuning the system for disturbance
rejection, or less aggressive control action when tracking SP changes.

4.6 The Fuzzy-HOBIC Summary
In summary, the HOBIC can be extended using the FL approach, yielding the Fuzzy-HOBIC.
The parameters that need to be specified/tuned for this controller are:
Input Variables:
o Slope (S):
L0
,
L1
,
L2
,
L3
, N
1
, N
2
(6)
o ErrorPercentage (EP): CTRL_TSH, DST_TSH, N
3
, N
4
(4)
Output Variable:
o deltaAction: N
5
-N
8
(4)

A total of 14 parameters need to be tuned so that the Fuzzy-HOBIC can start operating. The
process time-delay, minDelta and maxDelta values are assumed to be known inputs that depend
upon the application and the HOs behaviour, as well as the times involved to wait for the
system to react, after the control actions are given.

28
Although the adjustment of the Fuzzy-HOBIC parameters can be facilitated by observing past
HOs actions or by interviewing experienced operators in the particular loop of interest, the
manual adjustment of the membership functions can be a tedious and difficult task. To cope
with this disadvantage, an automatic method of tuning the developed Fuzzy-HOBIC using a
Genetic Algorithm is presented in the next chapter (Chapter 5).
29
Chapter 5: Applying a Genetic Algorithms Approach
to Tune the Developed Fuzzy-HOBIC
5.1 Tuning the Fuzzy-HOBIC - Overview
In Chapter 4, the Fuzzy-HOBIC was presented as an extension of the proposed HOBIC. It has
the advantage of being more flexible and easy to understand, since its concepts come from the
hypothetical HO model, formulated in Chapter 3. However, the main disadvantage of this
controller is the number of parameters that have to be specified/tuned: 14 parameters need to be
adjusted to adapt the behaviour of the Fuzzy-HOBIC controller to a given HO.

The concern in this Chapter is to develop an automatic procedure for tuning the Fuzzy-HOBIC
parameters. To handle these parameters in an easier way, the mapping described in Table 5.1 is
applied. This Table maps each Fuzzy-HOBIC parameter to the tags P
1
-P
14
. Note that P
1
to P
6

refer to the Slope variable while P
7
to P
10
are the ErrorPercentage parameters. The last
parameters, P
11
to P
14
, describe the output, deltaAction. These parameters have specific hard
constraints, since they define the inputs/output membership functions and they are listed in
Table 5.2.
Table 5.1: Mapping of the 14 Fuzzy-HOBIC parameters into the tags P
1
to P
14
, accordingly.
Parameter N
o
Fuzzy-HOBIC

Parameter N
o
Fuzzy-HOBIC
P
1 L0
P
8
N
3
P
2
N
1
P
9
DST_TSH
P
3 L1
P
10
N
4

P
4

L2
P
11
N
5
P
5

L3
P
12
N
6
P
6
N
2
P
13
N
7
P
7
CTRL_TSH P
14
N
8

Table 5.2: Hard limits of parameters.
Variables (inputs/output) Parameters Hard Constraints
Slope (S) 0
o
P
1
P
2
P
3
P
4
P
5
P
6
90
o
ErrorPercentage (EP) 0% P
7
P
8
P
9
P
10
100%

deltaAction 0% P
11
P
12
P
13
P
14
maxDelta (%)

30
When developing the automatic tuning procedure, these constraints have to be taken into
account. Thus, to analyse how many reasonable combinations are available to tune the Fuzzy-
HOBIC, suppose the resolutions of the parameters are as follows:

P
1
to P
6
: 1
o

P
7
to P
10
: 0.5%

P
11
to P
14
: 0.5%

For the tuning to be considered reasonable some other constraints, so called soft limits, are
introduced. For example: the parameter P
1
(Slope dead band limit) should not be greater than
10
o
-15
o
, since these values of angles start to be significant for considering an error decrease or
increase. Hence, thinking about these soft limitations, Table 5.3 applies.
Table 5.3: List of the soft limits applied for each parameter, and the number of values they can assume.
Parameter N
o
Soft Limits

N Values Parameter N
o
Soft Limits N Values
P
1
0
o
P
1
10
o
11 P
8
1% P
8
12%

23
P
2
1
o
P
2
15
o
15 P
9
1% P
9
30% 59
P
3
1
o
P
3
25
o
25 P
10
1% P
10
100% 199
P
4
1
o
P
4
35
o
35 P
11
0.5% P
11
5%

10
P
5
10
o
P
5
65
o
56 P
12
0.5% P
12
6%

12
P
6
10
o
P
6
90
o
81 P
13
0.5% P
13
11%

22
P
7
1% P
7
5% 9 P
14
0.5% P
14
12% 24

This Table can be constructed by an experienced operator for the particular loop to be
controlled, and thus depend upon the application. It is important to notice however, that once
these soft limits are defined, they will not be violated by the automatic tuning procedure.

The number of values that each of the parameters can assume is denoted by N in Table 5.3.
Thus, the maximum number of possible combinations is obtained by multiplying these values,
giving a value of 10
20
. This indicates that there is a large search space to seek for the optimum
tuning for the Fuzzy-HOBIC in a given control loop. Suppose the objective function is the sum
of squared errors between the manual operations and the automatic operation generated by the
Fuzzy-HOBIC. If this function takes 10
-2
s to be calculated, it will take 10
18
s to determine the
optimum tuning, if all the combinations are tested, which is 10
10
years. The reason for testing all
the combinations is that the 14 parameters of the Fuzzy-HOBIC determine an unknown function
that is likely to have local minimums. Ordinary optimisation algorithms are likely to get trapped
in these points, yielding sub-optimal solutions. Furthermore, preliminary tests in a given
31
application (Chapter 6) show that using the described objective function, the time necessary to
calculate the objective value is more than a second. This makes the time to search for the
optimum by testing all the possibilities even longer and too prohibitive to be applied.

Therefore, instead of searching for the optimum tuning, an algorithm is developed based on the
Genetic Algorithms approach [11] to find a suitable set of parameters for the controller in a
given application. In general, a Genetic Algorithm (GA) applies the Theory of Evolution,
defining, mathematically, biological operators such as mutation and recombination and applied
to an initial randomly generated set of possible solutions to produce a new population of
individuals/solutions. Based on the natural selection, the most suitable individuals of the
population are chosen where new mutations and recombinations are applied to them to yield the
next generation of, hopefully, better solutions. The rationale here is that as the population of
individuals evolves, it becomes more likely to obtain a best solution for the given problem.
The next Sections describe in further detail, how a GA is formulated and implemented in this
particular tuning problem.
5.2 Genetic Algorithm terms and definitions
To describe the applied GA to for Fuzzy-HOBIC tuning, several terms and definitions have to
be presented.

Figure 5.1: Chromosome definition of a hypothetic individual X from the population.

32
The 14 parameters of the controller (P
1
-P
14
) describe each individual from the population
intended to be evolved. These 14 parameters are then the genes that compose the chromosome
of each individual, as Figure 5.1 illustrates.

Another important decision to be made is about the way the genes are represented. In other
words, the genes encoding method needs to be defined. In general, binary coding is applied [14].
However, if binary coding is used for these 14 genes, analysis of the chromosomes values
would not be easy. Hence, a procedure of converting this binary coding (genotype), into real
values that describe the Fuzzy-HOBIC parameters, so called phenotype, is needed. Also, when
initialising the population it might be desirable to insert some individuals that are considered to
be suitable ones. For example, instead of starting the population by randomly selecting the
individuals, some individuals coming from what are considered to be reasonable tunings for the
Fuzzy-HOBIC might be inserted in the population. A real-value encoding would facilitate this
process.

In this work, real-value encoding is used to describe the genes of a chromosome. The next step,
before describing how the implemented GA works in more detail, is to define the biological
operators: mutation and crossover (also called recombination). It is important to understand
these operators since the offspring of a given pair of individuals is obtained after applying them.

A new individual is first produced by recombining the genetic material from a pair of existing
individuals. As Figure 5.2 illustrates, two different kinds of crossover are used in this work:
single and double-point crossover. These crossover methods are a natural extension of the
binary crossover. It is important to notice, however, that there are other crossover methods
which are not applied here, such as line or intermediate recombination [14]. The reason for not
applying these techniques is that instead of only swapping the genes from the parents, the latter
two methods also modify the genes. In the present work, the procedure of modifying the genes
will be left to the mutation operator only.

After producing the offspring by applying the crossover operation, the mutation of the
chromosomes is performed. Figure 5.3 shows how this operator works in the case of real-value
coded genes and a mutation rate of 50%. This is different from the mutation in the binary coded
genes, where a given gene is swapped from 1 to 0 or 0 to 1 with a specified probability. In this
work, a random change is made instead. Thus, by applying this change, which is within the
specified parameters soft limits, a new gene is obtained as a mutation of its original value.

33

Figure 5.2: Example of single and double-point crossover.

Figure 5.3: Example of the real-value mutation being applied in an offspring (the mutation rate is 50%).

34
The implementation of these described operators, and several other low level methods explained
later are part of a package of functions implemented in for use with MATLABs Genetic
Algorithm Toolbox [14]. This package of functions and its documentation were found to be
very useful and easy to apply.

At this point, it is important to note that the implemented crossover and mutation operators will
not necessarily produce new individuals that respect the hard and soft limits (Table 5.2).
Therefore, additional levels of methods are necessary to guarantee that the generated genes
respect the specified constraints. A discussion about this and other methods to solve GA
problems with constraints is given in [15].

For example, if P
1
is equal to P
2
, say 5
o
, a mutation of P
2
can generate a number which is less
than P
1
. This would create an invalid MF and hence an invalid chromosome. To avoid such a
situation, the upper level function gaFuzzyHOBICMutate mutates the chromosome
sequentially, gene per gene, applying the mutation operator from [14], starting with P
1
. That is,
the limits for the next gene are generated depending upon result of the previous gene mutation,
thus ensuring that hard limits constraints are adhered to. The procedure implemented also
ensures that soft limits are obeyed.

To make sure the hard limits are not violated when applying the crossover operator, another
upper level function, called gaFuzzyHOBICCrossOver, was developed. In this function, the
already described lower level crossover functions (single and double-point crossover) are
applied. In particular, in the used GA Toolbox there is a version of these functions that always
try to produce new individuals (the reduced surrogate versions of the single and double-point
crossover). These versions are preferred because by generating new individuals the search is
optimised. However, the new individuals produced are not always valid. Hence, after generating
the individuals a procedure to check if they are valid chromosomes was developed
(gaFuzzyHOBICCheckChromosome). If the crossover does not generate valid individuals, the
procedure is repeated. If it is not possible to produce new valid individuals different from the
parents, then the parents are repeated as the offspring. This is an extreme case that might happen
when the parents are very similar to each other, when they will generate the offspring as a copy
of themselves. Further details about these upper level functions can be found in the Appendix.

5.3 GA Objective Function definition
Now that the relevant GA terms and reproduction operators have been described, it is necessary
to determine when an individual is considered to be a suitable one. The objective of the GA is to
35
find values of the parameters P
1
-P
14
that will make the Fuzzy-HOBIC approximate a given
HOs behaviour. The closer the Fuzzy-HOBICs actions are to the HOs ones the better is the
tuning. A suitable objective function, also called a fitness function [11], is given by Equation
(7), where (i) U
man
and (i) U
FHOBIC
represent the sample i of the manual and the Fuzzy-HOBIC
actions from a total of N available samples, respectively.

=
N
1 i
2
FHOBIC man
N
(i)) U (i) (U
J (7)

5.4 Implemented GA general description
This Section presents an overview of how the GA is implemented to solve the Fuzzy-HOBIC
tuning problem. Before giving the detailed description of the implemented GA, it is worth
expanding the view of the GA method given at the end of Section 5.1.

Figure 5.4: A general genetic algorithm block diagram.

Figure 5.4 gives a simplified description of the implemented GA behaviour. From this figure, it
is possible to see that the first step is to generate the initial population (Population Initialise
block). In this step, as stated before, some suitable individuals, already known, can be inserted
in the random population to speed up the search procedure.
36
Next, is the Objective Function Calculation block. Here, the objective function values of each
new individual are calculated. Afterwards, the individuals have to be selected for breeding
(Selection block). The individuals that have higher fitness values are more likely to be
selected more than once, and hence are likely to generate more offspring. This is a reasonable
approach, since a suitable individual tends to give suitable offspring after breeding with another
proper individual. Several methods of selecting the individuals are described in the literature.
The Genetic Algorithm Toolbox used in this work provides two of them: the Stochastic
Sampling with Replacement algorithm (SSR) and the Stochastic Universal Sampling (SUS).

The first method is based on the roulette wheel selection scheme described in Figure 5.5, where
it is clear that the most suitable individuals of the population have the greatest probability of
being selected for breeding. The disadvantage of this method is that there is a possibility of all
the selected population being just from one individual, leading to the so called unlimited spread
[14]. The SUS method copes with this disadvantage, imposing a minimum spread. The SUS
algorithm, instead of having one pointer and choosing its position by a random number, has N
equally spaced pointers, with the starting pointer being random. Hence, whenever a given
pointer is indicating a certain individual, such as in Figure 5.6, this individual is selected for
breeding. Therefore, because of the stated advantage of the SUS method, it was chosen to be
applied in the present work. It is also worth noting that, in this method, the individuals are also
shuffled prior to the generation of the pointer, as Figure 5.6 demonstrates. From this Figure it is
possible to verify that the individuals I
1
, I
2
, I
6
and I
5
were chosen for breeding, with I
1
and I
6

(most suitable individuals) being chosen twice.

Figure 5.5: Roulette wheel selection method.
37

Figure 5.6: SUS selection method.

It is important to make sure that the individuals selected for breeding are arranged in such a way
that the pairs are not identical as this would cause the crossover to generate offspring that are
copies of the parents, as already stated before.

Having selected the individuals for breeding and arranging them properly, the generation of the
offspring takes place. In this block, as can be seen in Figure 5.4, the recombination and mutation
operators are applied in sequence. At this stage, a rate of mutation and recombination of the
individuals has to be selected. These rates indicate the probability of a pair of individuals to be
mated and the probability of a given individual gene to be mutated, respectively.

After generating the offspring (N individuals) and calculating the new fitness values (Obj
Function Calc block), in the Natural Selection block, these new individuals are compared
with the parents and the N most suitable ones, where N is the original population size, are
carried forward to the next generation (lowest fitness values). The evolution process then
continues.
5.5 The implemented GA particular aspects
The previous Section gave a general description of the implemented GA to solve the Fuzzy-
HOBIC tuning problem. In this Section, some particular aspects are clarified in order to provide
a better understanding of the implemented algorithm.

38
In the previous Section, it was stated that the mutation and recombination rates need to be
specified. The following reasoning is used to specify these rates. The population is divided
equally into three subpopulations, SubPop1, SubPop2 and SubPop3. SubPop1 is made up of the
N/2 most suitable individuals. SubPop2 is a copy of SubPop1, while SubPop3 is composed of
the least N/2suitable individuals. This division has a particular reason.

For the first set of best individuals (SubPop1), a low mutation rate is applied (1 gene per
individual, on average). It is a reasonable assumption that better individuals can be found close
to the original ones for this subpopulation. Thus, this first subpopulation evolves as a local
minimum search. The third subpopulation relates to the reverse situation. It is desirable to
search for individuals that are far from the ones from this population, since they are not suitable.
Hence, a high mutation rate is applied (almost all genes per individual are mutated, on average).
Therefore, in SubPop3 the GA is searching for other suitable regions of individuals that will
hopefully be new local minimums. The reason for creating a copy of SubPop1 is that this
subpopulation might not be suitable enough and hence, more suitable regions can still be found
far from those individuals. Thus, a high mutation rate is also applied for this subpopulation
(SubPop2).

For all the described subpopulations, a high crossover rate is applied. The reason for using a
high crossover rate (100%) is to enforce breeding of selected pairs of individuals. The intention
of imposing the breed is trying to generate different individuals. Hence, when applying the
Natural Selection block, the best N individuals can be chosen amongst the parents and the
generated offspring (a total of N+3N/2 individuals).

The question now is when the GA search should be stopped. The convergence criteria applied in
this work is either when the best individual from the population does not change for more than
N
G
generations or when the maximum number of generations (Total
NG
) is exceeded. After
testing several N
G
numbers, the criterion of 10 generations without changing the best individual
appears to be a suitable specification for detecting the most adequate tuning from the search,
considering the application tested (Chapter 6). The maximum total number of generations was
set to be 110, to allow up to 100 generations to find the best individual and apply the first
convergence criterion. The GA terminated before achieving this number for all the tests
performed, which is a desirable behaviour, meaning that the GA is converging to a solution.
These, together with the results of an investigation into the repeatability of the solutions
generated by the GA will be discussed later in Chapter 6.

39

Figure 5.7: Description of the implemented GA to solve the Fuzzy-HOBIC tuning problem.

To summarise, the implemented GA is shown in Figure 5.4. The results obtained after running
this algorithm are presented in the next chapter where some questions, including the following,
are answered:

How does the convergence criterion of the best individual evolve with the generations?
From which subpopulations do the new individuals (offspring) come from?
How do the objective values of the best individuals evolve through the generations?
40
Chapter 6: Results and Discussion
6.1 A Practical Process Control Application
Chapters 3 and 4 presented the theory necessary to understand the overall description of the
proposed controller. A procedure for the automatic tuning of the Fuzzy-HOBIC was given in
Chapter 5. The present chapter aims to show the behaviour of the developed controller in a
practical process control application, as well as the HOBICs one.

The application chosen for testing the HOBICs (HOBIC and Fuzzy-HOBIC) is controlling the
level of liquid in a Tank (Figure 6.1), in the same manner as performed in [9]. This is a very
common nonlinear application in the process industry. Hence, it is desirable to verify if the
developed controller can operate this loop acting as if it was a HO, supposing that this specific
loop was being manually controlled. For this specific application, it is also supposed that the
level needs a tight control. In other words, the controller (HOBIC or Fuzzy-HOBIC) will try to
keep the level at a desired SP, apart from undesired disturbances. SP-tracking tests are
considered as well.

Figure 6.1: Process Control Application scheme: controlling the level in a tank.
41
For the system shown in Figure 6.1, it is intended to regulate or track the tank level by
manipulating the valve V
1
that controls the inlet flow (Q
i
). The disturbance in this system is
considered to be any modification in the outlet flow (Q
o
), caused by the opening/closing of
valve V
2
. The manipulation of V
1
is done either by the HOBICs or by the HO. The operator is
presumed to be in the Control Room, sending the manual actions signals though the DCS
(Distributed Control System) software. He is also able to switch the system to automatic, where
one of the HOBICs will take over the control of the loop. The control signal (u) values vary
from 0% to 100% and refer to the percentage of the Control Valve (V
1
) opening (100% - fully
opened).

The overall behaviour of the tank level system is given by Equation (8), where A is the cross-
sectional area of the tank, h is the tank level, k is the valve coefficient, proportional to the
valve opening; k
d
is the amount of variation in the valve opening/closing.

h ) k (k Q Q Q
dt
dh
A.
d i o i
= = (8)

The values for the system parameters A, k and the maximum inlet flow Q
imax
(when V
1
is fully
opened) are chosen as follows:

=
=
=
s
s
/ cm 1200 Q
/ cm 75 k
cm 280 A
3
imax
2.5
2
(9)

Preliminary tests indicated that this choice of values makes the tank level system sufficiently
sluggish so it can simulate a real process control tank level application. In particular, the choice
of Q
imax
gives controllability to the system over the desired range (from min Level to max
Level), considering the output flow rate, determined by the choice of the k value. In Figure 6.1,
min Level is 0 cm and max Level is 150 cm. In this example, the distance between min
Level and the bottom of the tank is assumed negligible. Although these parameters will not
change within the scope of this work, the developed simulation system, presented in the
following Section, allows the user to modify them.

6.2 System Simulation with Graphical User Interface
After defining the application to test the HOBICs it is necessary to develop a simulation
environment that reflects the proposed system to be controlled. This Section shows the
42
implementation of a Graphical User Interface (GUI) to simulate the DCS software, through
which the operator controls the tank level system. The interface is built using the MATLAB
GUIDE (Graphical User Interface Development Environment) tool. Figure 6.2 shows the
developed interface.

Figure 6.2: GUI that simulates the DCS that operates the tank level system.

As can be seen from this Figure, the tank level process variable (PV) is shown in a graph on the
left hand side of the GUI, while the Control Valve signals (OP) are presented on the right hand
side of the Figure. The interface enables the operator to either manipulate the valve directly,
when choosing the Controller Option as Manual, or let the HOBIC or Fuzzy-HOBIC operate,
when switching to the Automatic mode and choosing the appropriate controller.

While in Manual mode, only the Inlet Flow - Valve Control box becomes active, where the
HO can change the valve aperture by either manipulating the slide control, that indicates the
43
minimum (0%) and maximum (100%) control signal output values, or inputting the desired
values for the Valve Opening (%) in the available text box.

After switching to the Automatic mode, the HOBIC or Fuzzy-HOBIC assume the control of the
loop. Hence, only the Inlet Flow Automatic Control box becomes active. The HO can now
change the SP values for the tank level system by placing the new desired values in the
indicated text box. The current PV value is displayed in the Current Tank Level text box.

As can be seen from the Figure, other options are also available for the tank level system. In the
box Options it is possible to change the initial tank level value, in the specified text box. It is
also possible to add noise to the system and random disturbances, by clicking in the appropriate
check-boxes shown in this Figure, at any time of the simulation. The Single Measurement
Error check-box simulates a fault in the measurement system (Level Transmitter LIT, in
Figure 6.1) that will cause one single measurement to be far from the actual PV trend,
randomly, during the system simulation. This can be used to verify how the performance of the
controllers can be affected by this kind of fault, although such kinds of investigations are left as
suggestions for future work.

Furthermore, the Data Generation and Performance Test box enables SP-tracking (Up and
Down) and Disturbance Rejection (Up and Down) tests to be generated. In the SP-tracking tests,
the SP is changed in sample 11 of the PV trend graph (20% up or 20% down, accordingly). This
allows either the automatic controller to be tested or a manual operation to be generated, since
the operator will have to change the control signal to make the PV track this SP change.
Similarly, for the Disturbance Rejection tests (20% of change in the valve V
2
to open or close,
occurring in sample 11) the controller can be tested or the manual operations can be generated.
The reason for generating the system changes always in the same sample is to enable an easy
comparison of the controllers performance with the manual operations.

From the developed interface, it is also possible to erase the current plots (Clear Plots button).
To start the simulation, the Start Simulation button is pressed. The check-box, Real Time
Simulation, allows the time intervals that the samples are displayed in the PV trend to be
greater (approximately 0.5 s), so it simulates a real process control application when receiving
the PV samples from the field. When the system is operating in automatic, this box can be
unchecked, so the results are generated faster. The interface also provides a Debug mode
check-box. When this box is checked, it is possible to investigate, through the MATLAB
command prompt, how the controller is performing its control strategy (which rules are being
used, what are the Slopes values, etc.), for example.
44

It is also possible to save the PV trend and Control Valve actions in a .mat file by using this
GUI. This is useful, for example, when generating the manual operations to be used for tuning
the Fuzzy-HOBIC, or saving a given controllers performance test after the tuning procedure.
The saved files can also be opened with the GUI.

(a)

(b)
Figure 6.3: GUI Menu in detail.

Figure 6.4: HOBIC parameters GUI.
45

Figure 6.5: Fuzzy-HOBIC parameters MATLAB FIS editor.

Figure 6.6: Tank Level Parameters definition.

The developed GUI also allows the user to change the tank level parameters defined in Section
6.1 (Cross-sectional tank area, k and Q
imax
), as already stated. The System Parameters are shown
in Figure 6.6.

In summary, the menu items, shown in detail in Figure 6.3, are:
File: open, save or exit the program;
Simulation: start and stop the simulation;
Controllers Options: To set either the HOBIC or the Fuzzy-HOBIC controllers
parameters. The HOBIC parameters dialog box is shown in Figure 6.4. To set/fine tune
46
the Fuzzy-HOBIC parameters, the MATLAB Fuzzy-Inference System (FIS) editor is
called through the menu Fuzzy-HOBICGeneral Block Diagram. The editor is
displayed in Figure 6.5. As shown in Figure 6.3(a), the rules and membership functions
editors can also be directly called from the developed GUI.
System Parameters: To set the Tank Level System parameters (Cross-sectional area, k
coefficient, total simulation time, etc.), presented in Figure 6.6, where the parameters
default values, used in all the simulations, are shown.

After presenting the developed environment where the controllers are tested, the results of the
controllers performance can now be shown. However, since the Fuzzy-HOBIC is a natural
extension of the HOBIC, the results are focused in the extended controller version. To tune the
Fuzzy-HOBIC membership functions by applying the automatic tuning procedure described in
Chapter 5, manual operations of the tank level have to be generated. The method used to
generate the manual operations is presented in the next Section, where the graphs showing how
the HO acts in the Control Valve are also displayed.

6.3 Manual Operations Generation
The manual operations of the tank level are generated using the developed Tank Level GUI. In
particular, the Data Generation and Performance Test options from the GUI (Figure 6.2) are
applied here, as stated in the previous Section.

Four manual operations sets are generated, as follows:
Disturbance Rejection: up and down tests
SP-Tracking: up and down tests

To start operating the Control valve at the exact moment the SP changes or the disturbance
occurs, the operator receives a warning dialog box informing him that a change is going to
occur in the system (either SP change or Disturbance rejection). An example of the dialog box is
shown in Figure 6.7. The objective of synchronising the operator actions with the changes is
that the HOs behaviour will not be delayed after a system change. For example, if a disturbance
occurs and only after some time the operator realises it has occurred, his action might be more
aggressive then it would be if he was aware of the change from the very beginning.

Furthermore, it is important to keep this synchronisation, since when running the GA the Fuzzy-
HOBIC actions will be generated by having as inputs the SP, PV and manual actions (U
man
)
samples from the manual operation. Hence, the system response will not be generated by the
47
Fuzzy-HOBIC actions, because in a practical application, the model of the system might not be
known. The Fuzzy-HOBIC will observe the PV samples and take the action as if it was
controlling it in automatic. Then the controllers actions are compared with the manual ones
using the objective function presented in Chapter 5, repeated here in Equation (10). Without
synchronising the system change with the operators actions, the resulting Fuzzy-HOBIC tuning
would not be meaningful. However, as this synchronisation might not be perfect, since the
operator has to click Ok on the dialog box and then start operating the valve, the resulting GA
tuning might require further fine tuning.

=
N
1 i
2
FHOBIC man
N
(i)) U (i) (U
J (10)

Figure 6.7: Generating manual operations for a level disturbance (20% up).

The GA is configured for tuning the Fuzzy-HOBIC for Disturbance Rejection and for SP-
Tracking. When in the first tuning mode, data from the Disturbance Rejection manual operation
is used, while SP-tracking data is used for the second mode of operation. The reason for not
using all the data to create one controller tuning only is based on the assumption of the HOs
hypothetic model, described in Chapter 3, which states that the operator clearly uses two
48
different modes of operation when controlling a loop, with the Disturbance Rejection mode
being more aggressive than the SP-tracking one. It is found in this study that tuning the
controller separately for SP-tracking and disturbance rejection give better performance. This
assumption of two modes of operation can be seen if one inspects Figure 6.8 to Figure 6.11.
These are the generated manual operations for the specified SP-tracking and Disturbance
Rejection tests.

Figure 6.8: Manual Operation: step up test (20%).

Figure 6.9: Manual Operation: step down test (20%).
49

Figure 6.10: Manual Operation: disturbance rejection up (20% valve V
2
- closing).

Figure 6.11: Manual Operation: disturbance rejection down (20% valve V
2
- opening).

Regarding the way these manual data is presented to the implemented GA, it is important to
highlight that instead of storing the SP-tracking or the Disturbance-Rejections data sets into two
single files, they are split into four different files. The reason for performing this split is to avoid
the discontinuities that would be present in the control actions when concatenating the data. As
can be seen from Figure 6.8 to Figure 6.11, the final control action values are different from the
initial ones. These discontinuities can fool the tuning algorithm when it attempts to cope with
50
this control action change, which in fact, is only a discontinuity problem. Also, in a practical
application, it would be desirable to split the data into different files, since it is not possible to
guarantee that the final control action of one test is equal to the initial control value of the other
test, unless the changes are done sequentially.

Therefore, when tuning the controller for SP-Tracking, the GA will use the data from the two
SP-tracking files (Figure 6.8 and Figure 6.9). While tuning the Fuzzy-HOBIC for Disturbance
Rejection, the two respective files are applied (Figure 6.10 and Figure 6.11). Nevertheless, only
the first 200 samples are taken from those files, because the PV and control actions achieve the
steady-state before that. Using less samples speed up the GA tuning, since the number of
samples impacts directly in the objective function calculation (Equation (10)).

An important remark that can be made about the manual operations data sets is that in a
practical application, a 20% disturbance in the valve V
2
in a single step would be considered a
large perturbation, unlikely to happen in ordinary conditions. However, this disturbance was
introduced to extract the operators behaviour in bringing the PV back to its original SP value
even when there is a great variation in the PV trend.

For the SP-tracking procedure, a 20% change in the SP is also considered to be a large change
in practice. However, while changing the SP, the operator has to deal with the plant
nonlinearity, which has more influence when changes in the tank level are large, since the
output flow is influenced by the square root of the level of the tank. This also explains the
choice of the initial tank level to generate the manual operations (100 cm). The effect of
nonlinearity is larger for greater level changes.

It is worth noting that although the term SP-tracking is often used only when controllers are in
automatic; it was introduced in Chapter 3 to describe the manual operations procedure of
changing the system operational point. This gives an idea of what is the desired PV value (SP)
and to what desired new value the operator is taking the PV (SP change). Hence, a comparison
between the manual mode and the Fuzzy-HOBIC SP-tracking can be done.

6.4 GA tuning and the Fuzzy-HOBICs Performance Results
This Section shows the results obtained when the GA presented in Chapter 5 is used to tune the
Fuzzy-HOBIC controller for the tank level application described in Section 6.1. The
configuration of the GA for all the results obtained is as follows:

51
Population size (N): 32 individuals;
Maximum number of generations (Total
NG
): 110;
Convergence criteria:
1) 10 generations without changing the best individual or
2) If the maximum number of generations is exceeded.

The population size is desired to be even, because of the split done into subpopulations, as
explained in Chapter 5. Also, if the population size is not even, one individual will not be
recombined, since pairs of individuals are needed for breeding. With a population of 32
individuals, in each generation, 48 (3N/2) objective functions are calculated, generating 48 new
individuals (offspring). Using an IBM Thinkpad (Pentium M, 1.5GHz, 504Mb RAM)
calculation of the objective function value took, on average, 1.2 s, i.e. about 1 min per
generation. Increasing the population size would increase the time to complete each generation.
Since this choice of number of individuals in the population is within the range of common
choices for the GA population sizes [14], this number is kept the same for all the generated
results.

The maximum number of generations is taken to be 110 to allow the algorithm to converge
using the first convergence criterion, up to the generation number 100, as already mentioned in
Chapter 5. It is desirable for the algorithm to converge using the first criterion because it means
that the GA has not found a tuning better than the best one, encountered 10 generations before.
The second convergence criterion (maximum number of generations) is a timeout method,
where there is no direct evidence that the algorithm will stop finding better settings in the next
generations. Hence, it is desirable and expected that the GA will converge before 110
generations. If this is not the case for most of the tests performed, the population size or the
allowable maximum number of generations could be increased. Nevertheless, an investigation
that could be done if Total
NG
is exceeded is to see if the best objective values are only slightly
different (say less than 1%) per generation in the last 10 generations, for example. If this is the
case, it is likely that the GA is close to convergence and increasing the total generations
number is unlikely to produce a great change in the results. Thus, the final best individual could
be taken as the suitable Fuzzy-HOBIC tuning.

Regarding the parameters that need to be specified prior to the Fuzzy-HOBIC tuning, which are:
minDelta, maxDelta, process time-delay, and time to wait between actions, as already
mentioned at the end of Chapter 4, the following is applied:

52
Process time-delay: 1 sample. Although the tank level dynamics does not have time-
delay, the sampling process introduces at least one sample of time-delay;
MaxDelta = 12% and MinDelta = 0.3%. The value of MaxDelta was obtained
empirically, after the manipulation of the tank level system in manual. The values of
minDelta that the operator uses are, in fact, 1%. However, a lower value was applied,
since the calculation of the Fuzzy-HOBIC output, through the Deffuzification process,
uses the centroid method. Therefore values greater than 1% would always be obtained if
minDelta was set to be 1%, generating more aggressive actions than the HO.
The time to wait between actions, has to be specified in terms of number of samples. As
stated in Chapter 4, this time has to be greater than the process time delay and is
proportional to the deltaAction absolute values. In other words, greater deltaActions
will have greater times to wait for the system to react. In case of SP-tracking, the times
to wait are 3 samples (time-delay + 2 samples), for small deltaActions, and 9 samples
(time-delay + 8 samples) for greater deltaActions. To be considered small the action
has to be less than the parameter N
5
, from the Fuzzy-HOBIC output variable shown in
Figure 6.12. For disturbance rejection, the times are 3 and 5 samples, respectively. As
expected, the time to wait before the actions is much less for the disturbance rejection
behaviour, when applying greater actions. This reflects the willingness of the operator
to remove the disturbance, resulting in a more aggressive behaviour.

Figure 6.12: Using parameter N
5
to determine whether the deltaAction is "small" or not.

Note that the procedure to obtain these parameters was by inspection and manual operation
experience, considering the particular system and the sampling time used. For example, if a
greater sampling time was applied, the times to wait would be shorter. An automatic method to
53
specify these parameters could speed up this procedure but this is outside the scope of this
study.
6.4.1 Running the GA for SP-tracking tuning
As stated in Section 6.3, when running the GA for SP-tracking, the manual data sets used to find
the adequate tuning for the Fuzzy-HOBIC are shown in Figure 6.8 and Figure 6.9. For each
generation, the following steps are taken, as already described in Chapter 5, but summarised
here for clarity:
1) Split the population into 3 subpopulations. The first one is composed of the best
individuals. The second one is a copy of the first one. The remaining individuals are
placed in the third subpopulation;
2) Select the individuals for breeding. The Selection procedure is based on the idea that the
best individuals have the highest probability of being selected;
3) Perform recombination of the selected individuals followed by mutation. In the first sub-
population, the mutation rate is low. In the second and third populations, high mutation
rates are applied. To reduce the search space, soft and hard parameter limits are respected
by applying the parameter constraints described in Chapter 5 (Table 5.2 and Table 5.3);
4) Calculate the objective values of the offspring (Equation (10));
5) Select from the parents and offspring (a total of N+3N/2 individuals) the N most suitable
ones (lowest objective values), which will survive and form the next generation;
6) Verify if the convergence criteria were achieved. If not, go to the next generation.

To keep track of how the GA has evolved, several graphs are generated at the end of the
simulation, as shown in Figure 6.13 to Figure 6.19. These figures were generated after one of
the runs performed for the SP-tracking tuning procedure, using the developed GA.

Figure 6.13 shows how many individuals from the generated offspring continue to the next
generation. They are called the Surviving New Individuals because they were created in one
generation and survived into the next generation. The number of Surviving New Individuals is
displayed showing which subpopulation they come from. As the GA evolves, it is less likely to
find many better offspring from the current population. Hence, the number of Surviving New
Individuals tends to decrease with the generations, as can be seen in Figure 6.13. Also, it is
reasonable that, as the GA evolves, it is likely to find more new suitable individuals from
subpopulation 1 rather than from 2 or 3. This is because subpopulation 1 is used to find local
minimums, while the other two subpopulations search for other regions of minimum, as
described in Chapter 5. Therefore, when the GA is converging to a solution, it is less likely that
54
it will find other suitable regions. Figure 6.14 shows an enlarged portion of Figure 6.13,
covering the last few generations, illustrating this expected behaviour.

Figure 6.15 shows how the first convergence criterion behaves over the generations. Whenever
the best individual is kept after a generation, the number of generations without changing the
best individual is increased. On the other hand, when an offspring is found to be better than the
best individual of the population, the number is reset to zero.

Figure 6.16 shows the evolution of the best individuals objective function values of the
population. Each drop in the objective function values indicates that a new best individual was
found. These drops coincide with the reset of the counter displayed in Figure 6.15.

Figure 6.17 tracks where the best individuals of the population come from. The symbol *
indicates, for each generation, the origin of the best individual. The values 1, 2 and 3 refer to the
subpopulation number. As observed from the Figure, most of the best individuals come from
subpopulation 1, as expected. However, subpopulation 2 and even 3 were also able to find new
best individuals, as this Figure illustrates.

Finally, after the GA has converged, the resultant actions for the Fuzzy-HOBIC are generated
(Figure 6.18 and Figure 6.19). This graph merely gives an idea of how the Fuzzy-HOBIC will
behave, after applying the tuning found by the GA.

Having tuned the Fuzzy-HOBIC, it was tested by running the GUI application and the results
are shown in Figure 6.20 and Figure 6.21. The generated control signal by the automatic
controller is clearly close to the manual operation one in both plots. This yields a PV closed
loop behaviour (dashed line) which is difficult to distinguish from the PV trend when the system
is in manual (solid line). Also, different from [9], now the control actions have discontinuities
(stair-like signal) much like the manual operation ones and is closer to the way the operator acts,
rather then generating continuous control action signals.

55
0 10 20 30 40 50 60 70 80
0
2
4
6
8
10
12
Generation
S
u
r
v
i
v
i
n
g

N
e
w

I
n
d
i
v
i
d
u
a
l
s
Subpopulations Evolution

SubPop 1
SubPop 2
SubPop 3

Figure 6.13: Subpopulations Evolution per generation.
55 60 65 70 75
0
2
4
6
8
10
Generation
S
u
r
v
i
v
i
n
g

N
e
w

I
n
d
i
v
i
d
u
a
l
s

SubPop 1
SubPop 2
SubPop 3

Figure 6.14: Subpopulations Evolution per generation (showing the last few generations).
56
0 10 20 30 40 50 60 70 80
0
1
2
3
4
5
6
7
8
9
10
Convergence Criterion (nGBest) Evolution
Generation
n
G
B
e
s
t

c
o
u
n
t
e
r

v
a
l
u
e

Figure 6.15: First convergence criterion evolution per generation.
0 10 20 30 40 50 60 70 80
0
2
4
6
8
10
12
14
16
X: 76
Y: 0.6041
Best Individuals Objective Function Values Evolution Plot
Generation
B
e
s
t

I
n
d
i
v
i
d
u
a
l

O
b
j
e
c
t
i
v
e

F
u
n
c
t
i
o
n

V
a
l
u
e

Figure 6.16: Objective values evolution for the best individuals.
57
0 10 20 30 40 50 60 70 80
1
1.2
1.4
1.6
1.8
2
2.2
2.4
2.6
2.8
3
From where the Best Individual Comes From?
Generation
S
u
b
-
P
o
p
u
l
a
t
i
o
n

Figure 6.17: Where the best individuals come from?
0 20 40 60 80 100 120 140 160 180 200
100
105
110
115
120
125
L
e
v
e
l

(
c
m
)

0 20 40 60 80 100 120 140 160 180 200
62
64
66
68
70
72
74
Time
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)

PV
SP
Man
Fuzzy-HOBIC

Figure 6.18: Best individual (after the GA terminated) vs. Manual Operation (step up).
58
0 20 40 60 80 100 120 140 160 180 200
75
80
85
90
95
100
105
L
e
v
e
l

(
c
m
)

0 20 40 60 80 100 120 140 160 180 200
50
55
60
65
Time (s)
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)

Man
Fuzzy-HOBIC
PV
SP

Figure 6.19: Best individual (after the GA terminated) vs. Manual Operation (step down).

Figure 6.20: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Step up test.

59

Figure 6.21: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Step down test.

Although the results are satisfactory, because of the probabilistic nature of GA tuning, an
important question that may arise is whether these results are repeatable. In other words, is the
GA capable of finding similar tunings if it is run several times? This was investigated and the
results obtained were close to each other, as can be seen when all the results are plotted together
(Figure 6.22 and Figure 6.23). Again, the manual operations and PV trend are shown as solid
lines and the Fuzzy-HOBIC results, distinguished by the number 1, 2 and 3, are displayed in
dashed-lines. Although it cannot be guaranteed that the GA will always find suitable solutions,
the tests indicated that the tuning solutions produced consistent results.

It is important to emphasise, at this point, that the only different between the several runs of the
GA is the random numbers generated in each run. All the GA configuration parameters were
kept the same, as already stated at the beginning of this Section.

60
50 100 150 200 250
100
110
120
130
140
150
160
L
e
v
e
l

(
c
m
)

0 50 100 150 200 250
60
65
70
75
80
85
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)
Time(s)

SP
PV Man
PV1
PV2
PV3
Man
Fuzzy-HOBIC1
Fuzzy-HOBIC2
Fuzzy-HOBIC3

Figure 6.22: Results of three GA tunings obtained (Step-up tests).
0 50 100 150 200 250
60
70
80
90
100
110
120
130
L
e
v
e
l

(
c
m
)

0 50 100 150 200 250
45
50
55
60
65
70
75
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)
Time(s)

SP
PV Man
PV1
PV2
PV3
Man
Fuzzy-HOBIC1
Fuzzy-HOBIC2
Fuzzy-HOBIC3

Figure 6.23: Results of three GA tunings obtained (Step-down tests).
61

Figure 6.24: Slope (input variable) for Fuzzy-HOBIC 1.



62

Figure 6.27: ErrorPercentage (input variable) for Fuzzy-HOBIC 1.


63

Figure 6.30: DeltaCtrlAction (output variable) for Fuzzy-HOBIC 1.


64
The settings obtained for the Fuzzy-HOBIC membership functions after running the GA are
displayed from Figure 6.24 to Figure 6.32. As can be seen from these figures, although some
variations can be observed in the tunings, the results shown in Figure 6.22 and Figure 6.23 are
quite similar to each other, indicating that there is a range of tunings that give close performance
results. Figure 6.24, Figure 6.27 and Figure 6.30 refer to the tuning of the Fuzzy-HOBIC that
generated the results shown in Figure 6.20 and Figure 6.21.

The results displayed in this Section show that it is possible to find a tuning for the developed
Fuzzy-HOBIC that will approximate the control actions of a HO operating the system in manual
for SP-tracking. The results for the disturbance rejection will be discussed next. Since
explanations about the type of graphs used to display the GA results and how the algorithm
works have been given, the disturbance rejection results will be presented in a more direct
manner.
6.4.2 Running the GA for Disturbance Rejection tuning
Before presenting the results of running the GA for disturbance rejection tuning, it is worth
verifying how the Fuzzy-HOBIC tuned for SP-tracking would behave when a disturbance
occurs. This would give an idea about the need of the developed controller to have a specific
tuning for disturbance rejection.

Figure 6.33 and Figure 6.34 show the actions of a controller tuned for SP-tracking compared to
the manual operation ones. It is clear that the controllers actions end up eliminating the
disturbance. However, it takes a longer time. In this case, if the system operated is critical, the
operator would possibly bypass the controller, switching it to manual, so he could eliminate the
disturbance faster. In particular, for the case of a step down in disturbance, the controllers
actions resulted in lower levels of fluid in the tank than when the system was in manual (Figure
6.34), which reinforces the idea that the operator would possibly switch the loop into manual to
eliminate the disturbance.

Hence, tuning the Fuzzy-HOBICs specifically for disturbance rejection is appropriate. Using
the disturbance rejection data sets presented in Figure 6.10 and Figure 6.11, GA evolution to the
best solutions are shown from Figure 6.35 to Figure 6.38. Figure 6.39 and Figure 6.40 give an
idea of the performance of the system using the converged parameters for the Fuzzy-HOBIC.
65

Disturbance Rejection up test.

Disturbance Rejection down test.

66
0 2 4 6 8 10 12 14 16 18 20
0
1
2
3
4
5
6
7
8
9
10
Generation
S
u
r
v
i
v
i
n
g

N
e
w

I
n
d
i
v
i
d
u
a
l
s

SubPop 1
SubPop 2
SubPop 3

Figure 6.35: Subpopulations Evolution per generation.
0 2 4 6 8 10 12 14 16 18 20
0
1
2
3
4
5
6
7
8
9
10
Convergence Criterion (nGBest) Evolution
Generation
n
G
B
e
s
t

c
o
u
n
t
e
r

v
a
l
u
e

Figure 6.36: First convergence criterion evolution per generation.
67
2 4 6 8 10 12 14 16 18 20
0
1
2
3
4
5
X: 19
Y: 1.005
Best Individuals Objective Function Values Evolution Plot
Generation
B
e
s
t

I
n
d
i
v
i
d
u
a
l

O
b
j
e
c
t
i
v
e

F
u
n
c
t
i
o
n

V
a
l
u
e

Figure 6.37: Objective Values evolution for the best individuals.
0 2 4 6 8 10 12 14 16 18 20
1
1.2
1.4
1.6
1.8
2
2.2
2.4
2.6
2.8
3
From where the Best Individual Comes From?
Generation
S
u
b
P
o
p
u
l
a
t
i
o
n

Figure 6.38: Where the best individuals come from?
68
0 20 40 60 80 100 120 140 160 180 200
98
100
102
104
106
108
110
L
e
v
e
l

(
c
m
)

0 20 40 60 80 100 120 140 160 180 200
40
45
50
55
60
65
Time (s)
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)

PV
SP
Man
Fuzzy-HOBIC

Figure 6.39:Best individual (after the GA has terminated) vs. Manual Operation (Disturbance up).
0 20 40 60 80 100 120 140 160 180 200
92
94
96
98
100
102
L
e
v
e
l

(
c
m
)

0 20 40 60 80 100 120 140 160 180 200
60
65
70
75
80
Time (s)
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)

PV
SP
Man
Fuzzy-HOBIC

Figure 6.40: Best individual (after the GA has terminated) vs. Manual Operation (Disturbance down).
69
The performance of the controller after tuning using disturbance rejection data was tested in the
developed GUI and the results are shown in Figure 6.41 and Figure 6.42. It can be seen that
although there are some slight differences between the control actions generated by the
controller and the manual operation, the performances of the closed loop systems are similar.

Applying the same reasoning used in the SP-tracking results, it is important to investigate
whether the results achieved in Figure 6.41 and Figure 6.42 are repeatable. Hence, the GA
tuning was run twice more to obtain other results. Figure 6.43 and Figure 6.44 show all the
performances plotted together. The resulting Fuzzy-HOBIC tunings for disturbance rejection
have the tags 4, 5 and 6. This is to differentiate them from the Fuzzy-HOBIC tunings found for
SP-tracking; these have tags 1, 2 and 3.

From Figure 6.43 and Figure 6.44 it is possible to observe that although there are some slight
discrepancies amongst the control signals, the responses of the PVs are close to each other. The
parameters of the membership functions of each variable employed by the Fuzzy-HOBIC are
shown from Figure 6.45 to Figure 6.53. In general, it can be concluded that they are consistent,
although some differences are present.

Figure 6.41: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection up
test.

70

Figure 6.42: Fuzzy-HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection
down test.
0 50 100 150 200 250
60
80
100
120
140
L
e
v
e
l

(
c
m
)

0 50 100 150 200 250
40
45
50
55
60
65
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)
Time(s)

SP
PV Man
PV4
PV5
PV6
Man
Fuzzy-HOBIC4
Fuzzy-HOBIC5
Fuzzy-HOBIC6

Figure 6.43: Results of three GA tunings obtained (Disturbance Rejection up tests).
71
0 50 100 150 200 250
80
100
120
140
L
e
v
e
l

(
c
m
)

0 50 100 150 200 250
60
65
70
75
80
C
o
n
t
r
o
l

A
c
t
i
o
n
s

(
%
)
Time(s)

SP
PV Man
PV4
PV5
PV6
Man
Fuzzy-HOBIC4
Fuzzy-HOBIC5
Fuzzy-HOBIC6

Figure 6.44: Results of three GA tunings obtained (Disturbance Rejection down tests).

72



73



Figure 6.51: DeltaCtrAction (output variable) for Fuzzy-HOBIC 4.
74



Finally, Figure 6.54 and Figure 6.55 show how the disturbance rejection tuned Fuzzy-HOBIC
would behave when there is a change in SP. As can be seen from these figures, the behaviour of
this Fuzzy-HOBIC is much more aggressive than manual operation. This, once more,
emphasises the idea that the HO uses two modes of operation when controlling loops in manual.
Therefore, as already stated, two different tunings have to be applied so the developed
controller can cope with disturbance rejection and SP-tracking modes of operation. Practical
implementation of the tuned controllers is discussed in Section 6.6.

75

lines). SP-tracking up test.

lines). SP-tracking down test.
76
6.5 The HOBICs Performance Results
As stated at the beginning of this Chapter, the results presented here are mainly focused on the
Fuzzy-HOBIC, since it is a natural extension of the HOBIC. However, it is possible, based on
the parameters from the obtained from GA tuning to specify the HOBIC parameters. Recalling
the Fuzzy-HOBIC membership functions schemes from Chapter 4 (Figure 6.56 and Figure 6.57)
one can remember how this correspondence can be done. After obtaining the HOBIC
parameters for SP-tracking and disturbance rejection, the respective performance tests can be
done. The results are displayed from Figure 6.58 to Figure 6.61.

From Figure 6.24, Figure 6.27 and Figure 6.30, where the Fuzzy-HOBIC membership functions
are displayed for one GA based SP-tracking tuning; the HOBIC Parameters for SP-tracking are,
as follows:
CTRL_TSH: 2.3%
DST_TSH: 8%
Slope Limits:
o
L0
: 5
o

o
L1
: 7
o

o
L2
: 17
o

o
L3
: 35
o

minDelta: 1%
maxDelta: 12%

Similarly, using Figure 6.45, Figure 6.48 and Figure 6.51 the HOBIC parameters for
Disturbance Rejection can be obtained:
CTRL_TSH: 2%
DST_TSH: 5%
Slope Limits:
o
L0
: 8
o

o
L1
: 18
o

o
L2
: 33
o

o
L3
: 48
o

minDelta: 1%
maxDelta: 12%

77

Figure 6.56: How to obtain the HOBIC parameters from the Fuzzy-HOBIC input variables.

Figure 6.57: How to obtain the HOBIC parameters minDelta and maxDelta.

78

Figure 6.58: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step up test.

Figure 6.59: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step down test.

79

Figure 6.60: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection up test.

Figure 6.61: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection down test.

As can be seen from Figure 6.58 to Figure 6.61, the HOBIC is also able to mimic the HOs
actions. This is an expected behaviour since the rules applied in the Fuzzy-HOBIC come from
the HOBICs ones. However, the results show that the deltaActions are more aggressive than it
should be, in some cases (Figure 6.58 and Figure 6.60). To reduce the aggressiveness of the
HOBIC, one simple approach, already described in Chapter 4, would be to reduce the range of
deltaActions that this controller can assume. Therefore, reducing maxDelta to 6%, the results
displayed from Figure 6.62 to Figure 6.65 are achieved.
80

Figure 6.62: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step up test after fine tune.

Figure 6.63: HOBIC (dashed lines) vs. Manual Operation (solid lines). Step down test after fine tune.

81

Figure 6.64: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection up test after
fine tuning.

Figure 6.65: HOBIC (dashed lines) vs. Manual Operation (solid lines). Disturbance Rejection down test
after fine tuning.

82
From these results, it is possible to conclude that the HOBIC, obtained from the Fuzzy-HOBIC
tuning can also emulate the HOs actions, presenting a control action behaviour which is similar
to manual operation, especially after the reduction of the range of the control signal output
values. Nevertheless, it has to be noted that this reduction of range leads to a controller that is
less flexible than the Fuzzy-HOBIC which, because it can operate over a wider output range
(0.3%-12%), it can cope with larger changes in operating conditions. Therefore, it is less likely
to be bypassed by the operator.

Instead of reducing the output range, another approach that could be used for the HOBIC would
be to add more parameters that could change the output division limits (DeltaAction) which, in
the present approach, are constant, as presented in Chapter 4. Nevertheless, this method would
increase the number of parameters that have to be specified. The Fuzzy-HOBIC controller
implementation has more flexibility and is easier to understand, since it applies linguistic terms
to describe the controller rules instead of simply applying directly, the range of angles or the
range of the control regions, as is required by the HOBIC.

6.6 Some Practical Application Issues
This chapter presented the results of applying the developed controllers to a process control
application via a developed Graphical User Interface that simulates a DCS software. However,
some practical issues have to be considered in a real implementation of the HOBIC:

Manual operation data can be chosen from past operations of the loop, if it has been
working in manual;
The parameters minDelta, maxDelta, can be set by either asking the operators of that
specific process or by inspecting the data selected for the Fuzzy-HOBIC GA tuning;
The process time-delay can also be obtained by inspecting the manual operation data, as
well as the times to wait for the next actions;

Another important aspect is that since the Fuzzy-HOBIC has two modes of operation (SP-
tracking and Disturbance Rejection), they have to be available for the operator to switch
between one and another, accordingly. The disturbance rejection mode should be the default,
because very often, it is desired to reject disturbances. When changing the SP, it should be
possible to automatically switch the Fuzzy-HOBIC to SP-tracking mode. However, if a
disturbance occurs during the SP-tracking, the operator has to be aware of it and switch the
controller back to disturbance rejection mode.
83
Chapter 7: Conclusions
In this work, a controller method is developed based on the way that the HO acts when
controlling a loop in manual. To be able to develop such a controller, a model of the operator is
first established. Based on this hypothetical intuitive model, the Human Operator Based
Intuitive Controller (HOBIC) is created.

To facilitate the overall understanding of the controllers behaviour and to increase its
flexibility, the HOBIC is extended to the Fuzzy-HOBIC, by applying the Fuzzy Logic Theory.
Afterwards, to cope with the problem of specifying parameters for the Fuzzy-HOBIC, an
automatic tuning method is developed based on the use of Genetic Algorithms. The Fuzzy-
HOBIC tuning is also used to set the HOBIC parameters.

The results of applying HOBIC and Fuzzy-HOBIC in a process control simulation have
indicated that:

The rules used to describe the HOs behaviour have been shown to be adequate for
approximating his manual operations;
It was possible to find a reasonable set of parameters for the HOBICs (HOBIC and
Fuzzy-HOBIC) that will approximate the behaviour of a given HO. However, the
Fuzzy-HOBIC approach has been demonstrated to be more flexible and easier to
understand. Hence, this should be the preferred implementation in a practical
application;
The HO has indeed two different modes of operation (SP-tracking and Disturbance
Rejection), which yielded two different tunings for the controllers;
A process model is not needed to tune the HOBICs. The tuning was performed by a GA
algorithm with historical process operational data under manual control, based on the
idea of generating the control actions that best fit the HOs ones. Hence, the process
model is embedded in the HOs behaviour, which was captured by the HOBICs.

Therefore, the HOBIC approach offers a new alternative for those loops in Industry that are
operating in manual. Since the HOBICs are able to approximate the HOs actions, creating
operator like signals (discontinuous), it is expected to gain better acceptance amongst the
operators, the end users of the controllers. By understanding the way these controllers behave, it
becomes less likely that they will switch them to manual and increase the statistics of loops that
are not in automatic in Industry.
84
Chapter 8: Recommendations for future work
As recommendations for future work, it is suggested:

Verify the impact of applying the Fuzzy-HOBIC approach in the presence of noise;
Test the developed controller in a real Process Control Application. Some of the
practical issues advised in this work could be considered;
Develop an automatic method for detecting the parameters needed prior to the Fuzzy-
HOBIC tuning, such as: minDelta, maxDelta, process time-delay and time to wait for
the next actions. Although it is possible to detect minDelta or maxDelta automatically
by simply investigating past data operation, the main difficulty in a practical application
would be choosing representative data. The robustness of both HOBICs to these
parameters can also be a subject of future work;
Investigate a possible strategy to be adopted for applications where the process time-
delay varies. In this case, even the operators would have difficulties in controlling the
loop in manual. However, a conservative method of choosing one appropriate dominant
time-delay or applying on-line detection of the time-delay to adapt the Fuzzy-HOBIC
would be possible approaches;
Build up a strategy of updating the tuning for the Fuzzy-HOBIC on-line. The on-line
tuning would be invoked if the operator decides that a specific Fuzzy-HOBIC action
was not adequate. The operator would then switch the controller into manual and make
the appropriate control action. At the same time, the controller would record the
operators new actions and then update its tuning so that this action can be generated
next time the same situation occurs. The feasibility of this approach could be
investigated;
The generated Fuzzy-HOBIC could be used to train apprentice operators, as already
suggested in [6]. The HOs would learn how to operate a given process by understanding
the rules and observing the controllers actions. The Fuzzy-HOBIC tunings are
generated using data from experienced operators. An interface, similar to the one
presented in this work, could be developed to facilitate the operators training.

85
REFERENCES:
[1] L. Desborough and R. Miller, Increasing Customer Value of Industrial Performance
Monitoring Honeywells Experience, Honeywell Hi-Spec Solutions. (2001). Available
at: <http://www.loopscout.com/Info/cpc2001desboroughandmiller.pdf> Last accessed:
06/07/2008.
[2] W. L. Bialkowski, Dream versus Reality: a view from both sides of the gap, Pulp and
Paper Canada, 94 (11), pp. 19-27 (1993).
[3] R. G. Costello, and T. J. Higgins, An Inclusive Classified bibliography pertaining to
modelling the human operator as an element in an automatic control system, VII IEEE
Symp. On Human Factors in Electronics, Minneapolis, Minn (1966).
[4] D. L. Kleinman, S. Baron and W. H. Levison, An Optimal Control Model of Human
Response Part I: Theory and Validation, Automatica, vol. 6, pp. 357-369 (1970).
[5] D. L. Kleinman, S. Baron and W. H. Levison, An Optimal Control Model of Human
Response Part II: Prediction of Human Performance in a Complex Task, Automatica,
vol. 6, pp. 371-383 (1970).
[6] G. O. A. Zapata, R. K. H. Galvo and T. Yoneyama, Extracting Fuzzy Control Rules
from Experimental Human Operator data, IEEE Trans. On Systems, Man and
Cybernetics-PartB: Cybernetics 29(3), pp. 398-406 (1999).
[7] S. E. Ertugrul and N. A. Hizal, Neuro-Fuzzy controller design via modelling human
operator actions. Journal of Intelligent & Fuzzy Systems 16, 133-140, IOS Press (2005).
[8] L. A. Zadeh, Fuzzy Sets, Information and Control 8, pp. 338-353 (1965).
[9] Y. M. Enab, Controller Design for an unknown process, Using simulation of a Human
Operator, Engineering Appl. of Artificial Intelligence 8(3), pp. 299-308 (1995).
[10] J. M. Mendel, Uncertain Rule-Based Fuzzy Logic Systems: Introductions and New
Directions, Prentice-Hall, Inc., Upper Saddle River, NJ, (2001).
[11] Introduction to genetic algorithms. Available at: <http://www.obitko.com/tutorials/genetic-
algorithms/index.php>. Last accessed: 19/06/2008.
[12] H. B. Nielsen, Introduction to vector and matrix differentiation, Lectures Notes.
Department of Economics. University of Copenhagen. Denmark. (2001). Available at:
http://www.econ.ku.dk/metrics/Econometrics2_05_II/LectureNotes/matrixdiff.pdf. Last
accessed: 21/06/2008.
[13] MATLAB version 7.2. The Fuzzy Logic Toolbox. For use with MATLAB. The
Mathworks, Inc. (2006).

86
[14] A. Chipperfield, P. Fleming, H. Pohlheim and C. Fonseca, Genetic Algorithm Toolbox:
For use with MATLAB - Software and Users Guide. Department of Automatic Control
and Systems Engineering. University of Sheffield. UK. (1994). Available at:
<http://www.shef.ac.uk/acse/research/ecrg/gat.html>. Last accessed: 26/06/2008.
[15] D. Orvosh and L. Davis. Using a Genetic Algorithm to Optimize Problems with
Feasibility Constraints, IEEE Conference on Evolutionary Computation - Proceedings
(2/-), pp. 548-553. (1994).
87
APPENDIX:
This Appendix includes the main source codes developed. However, for an investigation of all
the implemented source codes, refer to the CD-ROM attached to the present work. The CD
contains also a digital version of this dissertation.

A) HOBIC Implementation:
function controlAction = HOBIC(SP, PV, previousControlAction, directOrReverse)
%
% This is the Human-Operator Based Intuitive Controller (HOBIC).
%
% Inputs:
% SP - set-point (vector a containing two values SPnew(1) and SPold(2) )
%
% PV - process variable (vector)
%
% previousControlAction - previous value for the control action (signal
% between 0 and 1)
%
%
% directOrReverse - '1' - Direct action
% '-1' - Reverse action
% Output:
% controlAction - output to valve (signal between 0 and 100%)

% -------- HOBIC Parameters ---- From: "HOBIC_Parameters_GUI.fig" --------
global processTimeDelay CTRL_TSH DST_TSH TETHA1 TETHA2 TETHA3 TETHA_LOW_LIMIT
global maxDelta minDelta slopeDetectMethod
global fuzzyHOBICFlag %flag that indicates if the Fuzzy HOBIC is being used

%To define the deltaCtrlActions limits
global SMALL_CTRL_ACTION BIG_CTRL_ACTION

if(isempty(CTRL_TSH)) %The user did not modified any parameter
%Using the default values

if(fuzzyHOBICFlag == true)
%Take the limits info from the fuzzy HOBIC
%Reading the Fuzzy Inference System Created (FIS)
global fuzzyHOBIC %To be used in the DeltaCtrlAction function

if(isempty(fuzzyHOBIC))
fuzzyHOBIC = readfis('fuzzyHOBIC');
end

%Getting the Limits from the FIS
%Tetha Zero
TETHA_LOW_LIMIT = getfis(fuzzyHOBIC, 'input', 1, 'mf',4,'params'); %ZERO MF
TETHA_LOW_LIMIT = TETHA_LOW_LIMIT(3);

%Tetha Limits
%Slope Input
TETHA1 = getfis(fuzzyHOBIC, 'input', 1, 'mf',1,'params'); %SMALL MF
TETHA1 = TETHA1(3);
88

TETHA2 = getfis(fuzzyHOBIC, 'input', 1, 'mf',2,'params'); % MEDIUM MF
TETHA2 = TETHA2(2);

TETHA3 = getfis(fuzzyHOBIC, 'input', 1, 'mf',2,'params'); % MEDIUM MF
TETHA3 = TETHA3(3);

%Control Limits
%ErrorPercentage Input
CTRL_TSH = getfis(fuzzyHOBIC, 'input', 2, 'mf',1,'params'); % SMALL MF
CTRL_TSH = CTRL_TSH(3)/100;

DST_TSH = getfis(fuzzyHOBIC, 'input', 2, 'mf',2,'params'); % MEDIUM MF
DST_TSH = DST_TSH(3)/100;

%DeltaCtrlAction Limits
% MF 1 - Small (S)
SMALL_CTRL_ACTION = getfis(fuzzyHOBIC, 'output', 1, 'mf',1,'params');
SMALL_CTRL_ACTION = SMALL_CTRL_ACTION(3);

% MF 2 - Medium (M)
BIG_CTRL_ACTION = getfis(fuzzyHOBIC, 'output', 1, 'mf',2,'params');
BIG_CTRL_ACTION = BIG_CTRL_ACTION(4);

else
CTRL_TSH = 3/100;
DST_TSH = 0.1;
TETHA1 = 20;
TETHA2 = 30;
TETHA3 = 45;
TETHA_LOW_LIMIT = 5;
end

end

if(isempty(maxDelta))
maxDelta = 12;
minDelta = 1;
end

if(isempty(slopeDetectMethod))%The user did not defined the slope detction method
slopeDetectMethod = 1; %Use Least Squares as default
end

if(isempty(processTimeDelay)) %The user did not defined the process time delay
processTimeDelay = 1;
end

global errorPercentage %to be used in getSlope and deltaCtrlAction
global EP_LESS_CTRL %to be used in getSlope(1 and 2) and deltaCtrlAction

global debugFlagHOBIC

persistent timeCounter; % Counts the time to wait before making another control action
persistent waitTime;

if(isempty(timeCounter))
timeCounter = 0; %executes the first time it calls HOBIC funtion
waitTime = 0;
end
89

N_DATA = 5; %Analyse the last 5 samples (default) to determine the trend

minAmountOfData = N_DATA + ceil(processTimeDelay);

%If there is no sufficient data the HOBIC has to wait to decide what to do
if length(PV) < minAmountOfData
controlAction = previousControlAction;
return
end

if (timeCounter < waitTime)
timeCounter = timeCounter+1;
controlAction = previousControlAction;
else
timeCounter = 0; %resets to start to count again

%analyse a certain amount of data (N_DATA) to make the decision
data = PV((length(PV)-N_DATA+1):(length(PV)));

PV_last_value = PV(length(PV));

if(SP(1) ~= 0)
errorPercentage = abs((SP(1)-PV_last_value)/SP(1));
else
errorPercentage = abs(SP(1)-PV_last_value); %absolute error
end

EP_LESS_CTRL = (errorPercentage <= CTRL_TSH); %to be used in getSlope and deltaCtrlAction

%Choose the slope detection method
if (slopeDetectMethod == 0)%Filter (Obsolete - NOT USED)
[slope, tetha, errorSignal, positiveOrNegative] = getSlope(SP(1),data, length(data)-3, length(data));
%Compute the angle that the trend is making with respect to the SP
else
[slope, tetha, errorSignal, positiveOrNegative] = getSlope2(SP(1),data); %Compute the angle that
the trend is making with respect to the SP
end

%Compute the deltaControlAction
if(fuzzyHOBICFlag == true)
[deltaCtrl, waitTime] = deltaControlActionFuzzyHOBIC(tetha, errorSignal, positiveOrNegative,
directOrReverse);
else
[deltaCtrl, waitTime] = deltaControlAction(tetha, SP(1), PV_last_value, errorSignal, minDelta,
maxDelta, positiveOrNegative, directOrReverse);
end

if(debugFlagHOBIC == 1)
deltaCtrl%DEBUG
end

controlAction = previousControlAction + deltaCtrl;

%Saturation in the controlAction
if(controlAction > 100)
controlAction = 100;
elseif (controlAction < 0)
controlAction = 0;
end
90

end

function [slope, tetha, errorSignal, posiviteOrNegative] = getSlope2(SP,data)
% 1- This function calculates the slope of a given data.
% The input data should have a unic trend, so that the result can be
% meaningful.
%
% 2- This function also shows the direction of the trend. Shows if it is
% approaching or going far from the set-point.
%
% 3- getSlope2 is a variation of the getSlope function (obsolete).
% It uses the linear regression theory to compute the angle of the trend.
% It computes the slope that minimises the sum (y-y_hat)^2 of the
% given data. (Least Squares Method)
%
% Outputs
% slope - The slope of the given data (radians)
% tetha - The equivalent angle in degrees
% errorSignal - '1' : If the error is increasing (going far from SP)
% '-1': If the error is decreasing (trend is reaching the SP)
% '0' : Some unexpected situation occurred

global TETHA_LOW_LIMIT %The only HOBIC parameter used in this function
% ------------------------------------------------------------------------

%DEBUG FLAG
global debugFlagHOBIC %To activate or desactivate debug

global Ts %sample period applied

persistent LS_MATRIX %Compute the inverse matrix only once. Optimise th algorithm
%Assumes that the sampling period is constant during the
%simulation

%if not defined yet, define TETHA_LOW_LIMIT
if(isempty(TETHA_LOW_LIMIT))
TETHA_LOW_LIMIT = 5;
end

global EP_LESS_CTRL %parameters defined in HOBIC function
%Used here to determine which filter is going to be
%used (Gf1 or Gf2 - less aggressive)

%PV is data(length(data))
PV = data(length(data));

if(PV > SP)%Error (SP-PV) is negative
posiviteOrNegative = -1;
else
posiviteOrNegative = 1;
end

%Least Squares - NEW IMPLEMENTATION
if(isempty(LS_MATRIX))
N = length(data);
sampleTimes = ([0:N-1]').*Ts;
X = [ones(N,1) sampleTimes];
91

LS_MATRIX = pinv(X'*X)*X'; %inverse matrix calculation (just done once)
end

tethaVector = LS_MATRIX*data';
slope = tethaVector(2);

tetha = atan(slope);
tetha = tetha*180/pi; %tetha [degrees]

minTethaValue = TETHA_LOW_LIMIT; % Tight conditions

if abs(tetha) < minTethaValue
tetha = 0;
errorSignal = -1;
return; %There is no need to continue the code
end

errorSignal = 0; %If errorSignal output is zero, some unexpected situation
%may have occurred

%To obtain the error signal direction, four situations may occur
%
%1.1 - If the trend is going up and the error is increasing
%1.2 - If the trend is going down and the error is decreasing
%2.1 - If the trend is going down and the error is increasing
%2.2 - If the trend is going up and the error is decreasing

if(tetha > 0)
if( (data(length(data)) > SP) && (data(1) > SP)) %1.1 case
errorSignal = 1; %going far from SP
elseif((data(length(data)) < SP) && (data(1) < SP)) %2.2 case
errorSignal = -1; %reaching the SP
elseif((data(length(data)) > SP)&&(data(1) < SP))
else
errorSignal = -1;%Default
end
else
if(data(length(data)) > SP && (data(1) > SP)) %1.2 case
errorSignal = -1; %reaching the SP
elseif(data(length(data)) < SP && (data(1) < SP)) %2.1 case
elseif((data(length(data)) < SP)&&(data(1) > SP))
else
errorSignal = -1;%Default
end
end

92
function [deltaCtrl, waitTime] = deltaControlAction(tetha, errorSignal, minDelta, maxDelta,
positiveOrNegative, directOrReverse)
%To be Applied with The HOBIC
%This function outputs the amount of change that has to be applied to the
%control valve, as a function of the slope (tetha[degrees]) and the error = SP-PV.
%
% minDelta and maxDelta are parameters that describe the minimum and the
% maximum possible change in the control signal at once (values between 0 and 1,
% referring to percentage of openning - 100% is open). This values
% considers the Disturbance Rejection situation. For SP tracking the values
% used will be less aggressive.
%
% PV - latest PV value
%
% SP - latest SP value
%
% directOrReverse: control action choice
% '1' - direct action
% '-1' - reverse action
%
% positiveOrNegative - if the SP-PV signal is positive(+1) or negative(-1)
%
% errorSignal - -1 if the PV is getting closer to SP; Otherwise: +1.
%
% Outputs:
%
% deltaCtrl - The amount of change in the control signal (values between 0
% and 1)
%
% waitTime - Number of samples to wait
% for the system dynamics to make another control action
%

% Delta Control actions is calculated as a function of tetha

global processTimeDelay CTRL_TSH DST_TSH TETHA1 TETHA2 TETHA3
% ------------------------------------------------------------------------


%Thresholds - Defined in HOBIC function
global CTRL_TSH
global DST_TSH

% Boundaries for Tetha - HOBIC-PARAMETERS
Limit1 = TETHA1; %[degrees]

%Error percentage
global errorPercentage %defined in HOBIC as comment below
% if(SP ~= 0)
% errorPercentage = abs((SP-PV)/SP);
% else
% errorPercentage = abs((SP-PV)/100); %absolute error
% end

tetha
93
errorSignal
errorPercentage
CTRL_TSH
end

TETHA = abs(tetha);

%DeltaCtrl Action Limits - Using nomenclature from the report
D1 = minDelta;
D2 = (maxDelta-minDelta)/3 + minDelta;
D3 = 2*(maxDelta-minDelta)/3 + minDelta;
D4 = maxDelta;

%Conditions to be tested
TETHA_LESS_L1 = (TETHA <= Limit1);
TETHA_L1_L2 = ((TETHA > Limit1) && (TETHA <= Limit2)); %Tetha is between L1 and L2
TETHA_L2_L3 = ((TETHA > Limit2) && (TETHA <= Limit3)); %Tetha is between L2 and L3
TETHA_GREATER_L3 = TETHA > Limit3;

global EP_LESS_CTRL %defined in HOBIC
EP_CTRL_DST = (errorPercentage > CTRL_TSH) && (errorPercentage <= DST_TSH);
EP_GREATER_DST = (errorPercentage > DST_TSH);

%Rule 0
if (TETHA == 0) && (EP_LESS_CTRL) %No extra action has to be made
disp('RULE 0 - EP_LESS'); %DEBUG
end
deltaCtrl = 0;

elseif((TETHA == 0) && (EP_CTRL_DST))
disp('RULE 0 - EP_CTRL_DST'); %DEBUG
end

%Increase the control signal
deltaCtrl = positiveOrNegative*(-directOrReverse*D1);

return %Finishes the function
elseif((TETHA == 0) && (EP_GREATER_DST))
disp('RULE 0 - EP_GRATER_DST'); %DEBUG
end

%Increase the control signal - SHOULD CONSIDER USING a HIGHER VALUE HERE
deltaCtrl = positiveOrNegative*(-directOrReverse*D2);

%Rule 1 - Report (R4)
elseif TETHA_LESS_L1 && EP_LESS_CTRL % PV is in the Control Region
%"SMALL"
disp('RULE 1'); %DEBUG
end

if (errorSignal == -1) % Error decreasing
deltaCtrl = positiveOrNegative*(directOrReverse*((D2-D1)*(TETHA/Limit1)+D1));
else
deltaCtrl = positiveOrNegative*(-directOrReverse*((D2-D1)*(TETHA/Limit1)+D1));
end

94
%Minimum value for deltaCtrl is 1%
if(abs(deltaCtrl) < 1)
deltaCtrl = 1;
end

elseif TETHA_LESS_L1 && EP_CTRL_DST % PV is between CTRL_TSH and DST_TSH
%"SMALL"
end

deltaCtrl = positiveOrNegative*(directOrReverse*((D2-D1)*(TETHA/Limit1)+D1));
else
end

%Minimum value for deltaCtrl is 1%
if(abs(deltaCtrl) < 1)
deltaCtrl = 1;
end

elseif TETHA_LESS_L1 && EP_GREATER_DST
%"Medium"
end

%If Error is decreasing, should increase the control action to achieve
%faster the CTRL region
else
%If Error is increasing, should increase more the control action
end

elseif TETHA_L1_L2 && EP_LESS_CTRL % The angle is too high for the control region
%"SMALL"
end

%If Error decreasing, should lower a bit the control action. It is
%probably decreasing too fast
if (errorSignal == -1)% Error decreasing
deltaCtrl = positiveOrNegative*(directOrReverse*((D2-D1)*(TETHA-Limit1)/(Limit2-
Limit1)+D1));
else
%If Error is increasing, should increse the control action.
deltaCtrl = positiveOrNegative*(-directOrReverse*((D2-D1)*(TETHA-Limit1)/(Limit2-
Limit1)+D1));
end

%Rule 5 - Report (R8 & R9)
elseif TETHA_L1_L2 && EP_CTRL_DST % PV is between CTRL_TSH and DST_TSH
95
end

%If Error is decreasing, should keep the control action the same
deltaCtrl = 0;
else
%"MEDIUM"
Limit1)+D2));
end

elseif TETHA_L1_L2 && EP_GREATER_DST
end

%"SMALL"
Limit1)+D1));
else
%"MEDIUM"
%If Error is increasing, should increase more the control action.
Limit1)+D2));
end

%"SMALL"
elseif TETHA_L2_L3 && EP_LESS_CTRL % PV is in the Control Region
end

%If Error is decreasing, should decrease the control signal. Angle too
%high for the control region
Limit2)+D1));
else
Limit2)+D1));
end

elseif TETHA_L2_L3 && EP_CTRL_DST % PV is between CTRL_TSH and DST_TSH
end

%If Error is decreasing, should decrease a bit the control action
%"SMALL"
Limit2)+D1));
else
96
%"MEDIUM"
Limit2)+D2));
end

elseif TETHA_L2_L3 && EP_GREATER_DST
end

deltaCtrl = 0; %do not change
%"BIG"
else
Limit2)+D3));
end

%"MEDIUM"
elseif TETHA_GREATER_L3 && (EP_LESS_CTRL || EP_CTRL_DST) % Angle too high for these
regions
end

%If Error is decreasing, should decrease the control action
deltaCtrl = positiveOrNegative*(directOrReverse*((D3-D2)*(TETHA-Limit3)/(90-Limit3)+D2));
else
deltaCtrl = positiveOrNegative*(-directOrReverse*((D3-D2)*(TETHA-Limit3)/(90-Limit3)+D2));
end

elseif TETHA_GREATER_L3 && EP_GREATER_DST
end

%If Error is decreasing, should decrease the control action
%"SMALL"
else
%"BIG"
end
end

%WaitTime Definitions
if(deltaCtrl == 0)
waitTime = 0; %do not wait to take the next control action
elseif(abs(deltaCtrl) < D1)
%waitTime = processTimeDelay + 2; %For SP-TRK
97
waitTime = processTimeDelay + 3; %For DST_RJECT

else%MEDIUM and BIG deltaCtrl
end

deltaCtrl
end

98
B) Fuzzy-HOBIC Implementation:
function [deltaCtrl, waitTime] = deltaControlActionFuzzyHOBIC(tetha, errorSignal, positiveOrNegative,
directOrReverse)
%To be applied with The Fuzzy-HOBIC
%This function outputs the amount of change that has to be applied to the
%control valve, as a function of the slope (tetha[degrees]) and the error = SP-PV.
%
% directOrReverse: control action choice
% '1' - direct action
% '-1' - reverse action
%
% positiveOrNegative - if the SP-PV signal is positive(+1) or negative(-1)
%
% errorSignal - -1 if the PV is getting closer to SP; Otherwise: +1.
%
% Outputs:
%
% deltaCtrl - The amount of change in the control signal (values between 0
% and 1)
%
% waitTime - Number of samples to wait
% for the system dynamics to make another control action
%

% Delta Control actions is calculated as a function of tetha

global EP_LESS_CTRL CTRL_TSH DST_TSH TETHA1 TETHA2 TETHA3
global processTimeDelay
% ------------------------------------------------------------------------

global fuzzyHOBIC % Fuzzy Inference System Created (FIS)

%To define the deltaCtrlActions limits (By the FIS)
global SMALL_CTRL_ACTION

%Error percentage
global errorPercentage %defined in HOBIC as comment below
% if(SP ~= 0)
% errorPercentage = abs((SP-PV)/SP);
% else
% errorPercentage = abs(SP-PV); %absolute error
% end

%DEBUG FLAG
global debugFlagHOBIC %To activate or desactivate debug

tetha
CTRL_TSH
errorPercentage
DST_TSH
SMALL_CTRL_ACTION
end

TETHA = abs(tetha);

%EP_LESS_CTRL = (errorPercentage <= CTRL_TSH);
EP_CTRL_DST = (errorPercentage > CTRL_TSH) && (errorPercentage <= DST_TSH);
99

%Compute the DeltaCtrlAction (absolute value)
absDeltaCtrl = evalfis([TETHA; 100*errorPercentage; errorSignal], fuzzyHOBIC);

%Use the rules to verify if it is to open or to close the valve using the
%Computed absDeltaCtrl

%RULE 0 - Particular RULE
if(TETHA == 0)
% elseif (TETHA == 0)
disp('RULE 0 - R1 (Report)'); %DEBUG
end

deltaCtrl = positiveOrNegative*(-directOrReverse*absDeltaCtrl); %Increase control signal

%GENERAL RULE
else
disp('GENERAL RULE'); %DEBUG
end

if(EP_LESS_CTRL)||(EP_CTRL_DST)
disp('GENERAL RULE - Decrease CTRL signal - ES =-1'); %DEBUG
end

deltaCtrl = positiveOrNegative*(directOrReverse*absDeltaCtrl); %Decrease control signal
else
disp('GENERAL RULE - Increase CTRL signal - ES =-1'); %DEBUG
end

deltaCtrl = positiveOrNegative*(-directOrReverse*absDeltaCtrl);%Increase control signal
end
else
disp('GENERAL RULE - Increase CTRL signal - ES =+1'); %DEBUG
end

deltaCtrl = positiveOrNegative*(-directOrReverse*absDeltaCtrl); %Increase control signal
end

end

%WaitTime Definitions
if(deltaCtrl == 0)
waitTime = 0; %do not wait to take the next control action
elseif(abs(deltaCtrl) < SMALL_CTRL_ACTION)

disp('WaitTime - SMALL_CTRL_ACTION); %DEBUG
end


else%MEDIUM and BIG deltaCtrl
100
disp('WaitTime - BIG - else'); %DEBUG
end

%waitTime = processTimeDelay + 8; %For SP_TRK
end

101
C) GA Implementation:
%--------------------- gaFuzzyHOBIC Script--------------------------------
%
%This script implements the Genetic Algorithm for tuning the parameters of
%the FuzzyHOBIC
% -------------------------------------------------------------------------
clear all
%-------------------------------------------------------------------------
% Global Vars
%-------------------------------------------------------------------------
global fuzzyHOBICFlag
global slopeDetectMethod

global Total_nG %To be used in the Results generator script file

%DEBUG FLAG

debugFlagHOBIC = 0;

fuzzyHOBICFlag = true; %The HOBIC function will apply the FuzzyHOBIC

global processTimeDelay %Time delay of the process, used by HOBIC function
global Ts% Sampling time applied

global fileName
global rootDirect
global SP_vector PV_vector U_Man_vector
global files

%Get Fuzzy-HOBIC control action limits (from HOBIC)
global minDelta maxDelta

global N_SAMPLES % Num samples for each manual operation data set

%-------------------------------------------------------------------------
% CONSTANTS
%-------------------------------------------------------------------------

fileName = 'fuzzyHOBIC';
nRandPop = 30; %Random Population Number (even)
NG_TARGET = 10; %Convergence Criterion (Total number of generations without changing the best)
NG_MAX = 111; %Maximum number of Generations

%Mutation Rates
SUBPOP1_MUT_RATE = 0.1;
SUBPOP2_MUT_RATE = 1;
SUBPOP3_MUT_RATE = 1;

%Reproduction Rates
SUBPOP1_REP_RATE = 1;

%Directory to place the LogData
rootDirect = pwd;
rootDirect = strcat(rootDirect, '\LogDataFolder\');

%Constants File
102
[genFileName, errmsg] = sprintf('%sconstants', rootDirect);
genFileName = char(genFileName);
save(genFileName,
'nRandPop','NG_TARGET','NG_MAX','SUBPOP1_MUT_RATE','SUBPOP2_MUT_RATE','SUBPOP3
_MUT_RATE','SUBPOP1_REP_RATE','SUBPOP2_REP_RATE','SUBPOP3_REP_RATE');

%Define Process Time-delay Default value, if not defined
if(isempty(processTimeDelay))
processTimeDelay = 1;
end

%Define the Process sampling time, if not defined yet
if(isempty(Ts))
Ts = 1;
end

%--------------------------------------------------------------------------
% Training Data Set
%--------------------------------------------------------------------------

% DAY 04_06 DATA
%SP-TRK
% files = {'GA_Training_Data\04_06\SP_TRK\sp_trk_up_1.mat';
% 'GA_Training_Data\04_06\SP_TRK\sp_trk_down_1.mat';};
% 'GA_Training_Data\04_06\SP_TRK\sp_trk_down_2.mat';
% 'GA_Training_Data\04_06\SP_TRK\sp_trk_up_2.mat';};

%DST-RJECT
% files = {'GA_Training_Data\04_06\DST_RJECT\dist_reject_down_1.mat';
% 'GA_Training_Data\04_06\DST_RJECT\dist_reject_down_2.mat';
% 'GA_Training_Data\04_06\DST_RJECT\dist_reject_up_1.mat';};
% 'GA_Training_Data\04_06\DST_RJECT\dist_reject_up_2.mat';
% };
%--------------------------------------------------------------------------
% Loading DATA
%-------------------------------------------------------------------------
%Open Available the files and read the (SP,PV,U_man) values
%Getting training data
N_SAMPLES = 200;

for i = 1:length(files)
fullFilePath = char(files(i));

load(fullFilePath); %Load the saved (SP,PV,U_man) values

%Cutting data (first 250 samples) - speed up the GA
spValueSav = spValueSav(1:N_SAMPLES);
PVSav = PVSav(1:N_SAMPLES);
CtrlValveSav = CtrlValveSav(1:N_SAMPLES);

% Old implementation
SP_vector(:,i) = spValueSav;
PV_vector(:,i) = PVSav;
U_Man_vector(:,i) = CtrlValveSav;

end
%--------------------------------------------------------------------------
% Algorithm Implementation
%--------------------------------------------------------------------------
%Define minDelta & maxDelta Default values, if not defnined
103
if(isempty(minDelta))
minDelta = 0.3;
maxDelta = 12;
end

%Initialising population
chromosomes = gaFuzzyHOBICPopInitialise(nRandPop);

% Adding good individuals to the population
%Trial
chromosomes(nRandPop+1,:) = [1 5.0 6.69 13 15 20.9 33 1.0 5.65 12 16 1.5 1.8 3.3 5.65];

%SP_TRK - good
%chromosomes(nRandPop+2,:) = [1 6.65 8.69 12 15 18.9 21 2.5 6.65 10 11 1.0 2.0 2.5 6];

%DST_RJECT - good
chromosomes(nRandPop+2,:) = [1 8 15 18 25 33 50 2 8 10 60 1.5 2.5 4.3 8.3];

[N, M] = size(chromosomes); % Now, N is the total population number

if (mod(N/2,2)~=0) % N/2 is not even - The Cross-over will not be performed
N_subPops = N/2-1; % for all members of the subpopulations. It will gnerate N/2-1 individuals
else
N_subPops = N/2;
end

% ----------------------
% OBJ FUN CALCULATION
% ----------------------
for n=1:N
slopeDetectMethod = 1; %Using Least Squares method only (the other method is obsolete)

gaFuzzyHOBICChangeMF(chromosomes(n,:), fileName); %Change the FuzzyHOBIC parameters

objValues(n) = gaFuzzyHOBICObjFun(SP_vector, PV_vector, U_Man_vector); %Compute the
Objective function
end

% -------------------------------------------------------------------------
% GA - Kernel
% -------------------------------------------------------------------------
%------------------------
% Initialising variables
%------------------------

Total_nG = 1; %Starts at Generation 1
nG_Best = 0;

%For the best individual of the Population
best_ind = 0;
best_ind_objValue = 0;

elapsedTime = 0; %Execution time per generation
totalElapsedTime = 0; %Total Elasped Time

%Sort - Ascending order
[objValues sortIndex] = sort(objValues);
chromosomes = chromosomes(sortIndex,:);

while (Total_nG < NG_MAX) && (nG_Best ~= NG_TARGET)
104

tic %Counting time per generation

%------------------------
% Initialising variables
%------------------------
%To keep track of from which subPops the New Individuals (Best Selected) come from
newSubPop1(Total_nG) = 0;
totalNew(Total_nG) = 0; %newSubPop1+newSubPop2+newSubPop3

%-------------------------
% Split into 3 Populations
%-------------------------

%Subpop1 - First N/2
subPop1Chrom = chromosomes(1:N/2,:);
subPop1ObjValues = (objValues(1:N/2))';

%Subpop2 - First N/2 - Copy of Subpop1
subPop2Chrom = subPop1Chrom;
subPop2ObjValues = subPop1ObjValues;

%Subpop3 - Second N/2
subPop3Chrom = chromosomes(N/2+1:N,:);
subPop3ObjValues = (objValues(N/2+1:N))';

%----------------------------------------------------------
% Reproductions an Mutations
%----------------------------------------------------------

%-------------------------------------------------------
% Subpop1 (Best individuals): Reproduction, Low Mutation
%-------------------------------------------------------

subPop1FitnV = ranking(subPop1ObjValues);

%Select Individuals for reproduction/mutation - 'SUS' Algorithm
subPop1SelCh = select('sus', subPop1Chrom, subPop1FitnV);

%Reproduction
new_subPop1Chrom = gaFuzzyHOBICCrossOver(subPop1SelCh, SUBPOP1_REP_RATE);

%Mutation
new_subPop1Chrom = gaFuzzyHOBICMutate(new_subPop1Chrom, SUBPOP1_MUT_RATE);

%--------------------------------------------------------
% Subpop2 (Best individuals): Reproduction, High Mutation
%--------------------------------------------------------



%Reproduction

105
%Mutation

%---------------------------------------------------------
% Subpop3 (Worst individuals): Reproduction, High Mutation
%---------------------------------------------------------



%Reproduction

%Mutation

% --------------------------------------------------
% OBJ FUN CALCULATION of NEW Individuals (offspring)
% --------------------------------------------------

new_chromosomes = [new_subPop1Chrom; new_subPop2Chrom; new_subPop3Chrom];

[newN, M] = size(new_chromosomes); %If N/2 is not even

for n=1:newN
slopeDetectMethod = 1; %Using Least Squares method only

gaFuzzyHOBICChangeMF(new_chromosomes(n,:), fileName); %Change the FuzzyHOBIC
parameters

new_objValues(n) = gaFuzzyHOBICObjFun(SP_vector, PV_vector, U_Man_vector); %Compute
the Objective function
end

%----------------------------------------------------------------------
% REINSERTION - Selection of the Best Individuals for the Next Generation
%----------------------------------------------------------------------

%Sort New chromosomes - Ascending order
[new_objValues new_sortIndex] = sort(new_objValues);
new_chromosomes = new_chromosomes(new_sortIndex,:);

%Verify/Record who is the BEST individual of the Population
minValue = objValues(1);
newMinValue = new_objValues(1);

%Keep track of where the New Individuals come from
subPopIndex = [ones(1,N_subPops) 2*ones(1,N_subPops) 3*ones(1,N_subPops)];
subPopIndex = subPopIndex(new_sortIndex);

if(minValue <= newMinValue)
nG_Best = nG_Best+1; %No update in the Best individual of the Population

%For Generation 1
if(Total_nG == 1)
best_ind = chromosomes(1,:);
106
best_ind_objValue = minValue;
best_ind_origin = 1; %Consider that the best is from Subpop1
end
else %There is a New BEST
nG_Best = 0;
best_ind = new_chromosomes(1,:);
best_ind_objValue = newMinValue;
best_ind_origin = subPopIndex(1); %Identifies from where the best comes from
end

%REINSERTION in the Population - New version - Keep the N best out
%of: N(old population) + 3N/2 (offspring)
i = 0;
n = 1;
while (n <= newN) && (i <= N) %All the new Individuals are already investigated or N insertions
were made

hasEqual = objValues./new_objValues(n);
I = find(hasEqual == 1);

if(isempty(I)) % It means that the new individual has a obj value which is different from all the
values in the objValue vector

if(new_objValues(n) < objValues(N)) %Insert in the actual population if the new ind. is
better than the worse of the actual pop

objValues(N) = new_objValues(n);
chromosomes(N,:) = new_chromosomes(n,:);

%Sort objValues and chromossomes again - ascending
%order
[objValues sortIndex] = sort(objValues);
chromosomes = chromosomes(sortIndex,:);

if(subPopIndex(n) == 1)%New ind comes From subPop1
newSubPop1(Total_nG) = newSubPop1(Total_nG)+1;
elseif(subPopIndex(n) == 2)%New ind comes From subPop2
else%New ind comes From subPop3
end

%Increment the number of insertions
i=i+1;
end
end
n=n+1; %Investigate the next new individual
end

%Total of New Individuals that will survive for the next generation
totalNew(Total_nG) = newSubPop1(Total_nG)+ newSubPop2(Total_nG) +
newSubPop3(Total_nG);

%-----------------------
% Generation of Log File
%-----------------------
[genFileName, errmsg] = sprintf('%sGeneration%05d', rootDirect, Total_nG);
genFileName = char(genFileName);

elapsedTime(Total_nG) = toc; %Elapsed Time per Generation
107
totalElapsedTime = totalElapsedTime + elapsedTime(Total_nG);
save(genFileName,
'Total_nG','chromosomes','objValues','best_ind','best_ind_objValue','best_ind_origin','nG_Best','newSubP
op1','newSubPop2','newSubPop3', 'totalNew','elapsedTime');

%-----------------
% Next Generation
%-----------------
Total_nG = Total_nG+1;
end

Total_nG
nG_Best

%--------------------------------------------------------------------------
% RESULTS GENERATION
%--------------------------------------------------------------------------

run gaFuzzyHOBIC_ResultsGenerator

function [chromosomes] = gaFuzzyHOBICPopInitialise(NumIndividuals)
%
% This function generates a initial population for the genetic algorithm to
% tune the Fuzzy Logic HOBIC.
%
% All the developed Genetic Algorithm functions make use of the GA Toolbox
% developed by the University of Sheffield, England
%
% This function calls function 'crtbp' to generate the chromosomes.
%
%
% FLHOBIC chromosome format:
%
%
% Part 0 Part1 Part2 Part3
%
% SD T P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14
% __ __ | __ __ __ __ __ | __ __ __ __ | __ __ __ __
%
%Genes: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
%
% Describing each part of the chromosome and the range of each gene
%
% Part 0:
% Gene 0: Slope Detection Method(SD): 0 - Filter (Obsolete - NOT
% USED)
% 1 - Least Squares (Default)
%
% Gene 1: Tetha values to be ignored (T): 3..10 (degrees)
% This gene defines also the first parameter of the Slope
% membership function SMALL.
%
% Part 1 (Slope Membership Functions - MFs):
%
% Genes 2..3: MF-SMALL
% Parameter 2(P2): (P1+1)..20 (degrees)
% P3: (P2+1)..45 (degrees)
%
% Genes 4..5: MF-MEDIUM
% P4: (P3+1)..75 (degrees)
108
% P5: (P4+1)..89 (degrees)
%
% Gene 6: MF-BIG
% P6: (P5+1)..90 (degrees)
%
%
% Part 2 (Error Percentage MFs)
%
% Gene 7: MF-SMALL
% P7: 0..10 (%)
%
% Gene 8..9: MF-MEDIUM
% P8: (P7+1)..12 (%)
% P9: (P8+1)..30 (%)
%
% Gene 10: MF-BIG
% P10: (P7+1)..100 (%)
%
% Part 3 ( DeltaCtrlAction MFs)
%
% Gene 11: MF-SMALL
% P11: 0.5..5 (delta% - valve delta opening)
%
% Gene 12..13: MF-MEDIUM
% P12: (P11+1)..8 (delta%)
% P13: (P12+1)..11 (delta%)
%
% Gene 14: MF-BIG
% P14: (P13+1)..12 (delta%) - 12 is the MaxDeltaValue
%
%
% REMARK: For the DeltaCtrlAction, the MFs ZERO and MAX are not going to
% take part in the GA, as their values are fixed (zero and MaxDeltaValue).
%
% Constraints:
%
% When generating the chromosomes it is necessary to respect some
% constraints, otherwise the generated phenotype will have no meaning for
% the fuzzy HOBIC.
%
% Therefore:
%
% 0 < P1 < P2 < P3 < P4 < P5 < P6 < 90 (Part 1 constraints)
% 0 < P7 < P8 < P9 < P10 < 100 (Part 2 constraints)
% 0 < P11 < P12 < P13 < P14 < 12 (Part 3 constraints)

%Get Fuzzy-HOBIC control action limits (from HOBIC)

%For each chromosome to be generated:
%
% Generate the chromosomes based on the structure given
% Check if the constraints are being respected
%
for n = 1:NumIndividuals

%Generating population with the real-value coding
%
%Part 0
chrom_part0(n,:) = round(crtrp(1, [0 3; 1 10])); %(Gene0 - 0..1; Gene1 - 3..10)
109

%Part 1 - Slope
%Respect the constraints

%P2 > P1 (Gene 1)
P2 = round(crtrp(1, [chrom_part0(n,2)+1; 15]));

%P3 > P2
P3 = round(crtrp(1, [P2+1; 25]));

%P4 > P3
P4 = round(crtrp(1, [P3+1; 35]));

%P5 > P4
P5 = round(crtrp(1, [P4+1; 65]));

%P6 > P5 && P6 < 90
P6 = round(crtrp(1, [P5+1; 90]));

chrom_part1(n,:) = [P2 P3 P4 P5 P6];

%Part 2 - Error Percentage

%P7 > 0 && P7 < 5
P7 = round(10*crtrp(1, [1; 3]))/10; %Control Region Should be less than 3% - minimum of 1%

%P8 > P7
P8 = round(10*crtrp(1, [P7+0.5; 12])/10);

%P9 > P8
P9 = round(10*crtrp(1, [P8+0.5; 30])/10);

%P10 > P9 && P10 < 100
P10 = round(10*crtrp(1, [P9+0.5; 100])/10);

chrom_part2(n,:) = [P7 P8 P9 P10];

%Part 3 - DeltaCtrlAction - The resolution is 0.5

%P11 > 0
P11 = round(10*crtrp(1, [minDelta+0.5; 5]))/10;
%P11 = round(10*crtrp(1, [0.5; 5]))/10;

%P12 > P11
P12 = round(10*crtrp(1, [P11+0.5; 8]))/10;

%P13 > P12
P13 = round(10*crtrp(1, [P12+0.5; 11]))/10;

%P14 > P13 && P14 < 12
P14 = round(10*crtrp(1, [P13+0.5; maxDelta]))/10;

chrom_part3(n,:) = [P11 P12 P13 P14];

end

chromosomes(:,:) = [chrom_part0 chrom_part1 chrom_part2 chrom_part3];
110

function [newChrom] = gaFuzzyHOBICCrossOver(Chrom, RecProb, SubPop)
% Inputs:
%
% Chrom - vector os chromosomes (one chromosome per row)
% RecProb - recombination probability
% SubPop - (optional) Number of subpopulations
% if omitted or invalid number, 1 subpopulation is assumed
%
% This function uses the function 'recombin()', from the University of
% Sheffield GA TOOLBOX. Refer to this function for more details.
%
% The function will randomly select the recombination function to use,
% among those listed blow (functions from the University of
% Sheffield GA TOOLBOX):
%
% 1) xovsprs - Crossover Single-Point Reduced Surrogate
% 2) xovdprs - Crossover Double-Point Reduced Surrogate
% 3) xovsp - Crossover Single-Point
% 4) xovdp - Crossover Double-Point
%
% REMARK: The reduced surrogate means that the functions will try to
% generate new chromosomes, whenever it is possible.
%
% REMARK2: Options 3 and 4 were added just in case the chromosomes are
% too much similar and it is not possible to generate a different one
% which is valid (checked by the function gaFuzzyHOBICCheckChromosome)
%
% Last updated: 29/05/2008

%Choose Randomly which crossover function to use
%The first two options are more likely to be selected, since they tend to
%generate different chromosomes
choiceVector = [1 1 2 2 3 4];

persistent initialiseRand; %FIL - initialise rand function first - 28.06.2008

if(isempty(initialiseRand))
initialiseRand = 0;
end

if(initialiseRand ~= 1)
%Initialise rand function
rand('state',sum(100*clock));

initialiseRand = 1;
end

%Calling cross-over function
if nargin < 3, SubPop = 1; end %Default value of '1' is used

[N,M] = size(Chrom); %Getting the number of chromosomes available

%Need to split the chromosome vector into pairs of chromosomes
%Considering N as even. This is to check the consistency of the
%generated chromosomes
n=1; %index to get the pairs
111
for i=1:N/2
ChromPair = Chrom(n:n+1,:);

checkChrom = 0; %initialisation

while sum(checkChrom) ~= 2,
choice = ceil(6*rand(1)); % Random number between 1 and 6;

choice = choiceVector(choice); %Choose the cross-over method

if(SubPop == 1) %There is no subpopulation
switch (choice)
case 1
newChromPair = recombin('xovsprs', ChromPair, RecProb);
case 2
newChromPair = recombin('xovdprs', ChromPair, RecProb);
case 3
newChromPair = recombin('xovsp', ChromPair, RecProb);
case 4
newChromPair = recombin('xovdp', ChromPair, RecProb);
end
else %There is a subpopulation
switch (choice)
case 1
newChromPair = recombin('xovsprs', ChromPair, RecProb, SubPop);
case 2
newChromPair = recombin('xovdprs', ChromPair, RecProb, SubPop);
case 3
newChromPair = recombin('xovsp', ChromPair, RecProb, SubPop);
case 4
newChromPair = recombin('xovdp', ChromPair, RecProb, SubPop);
end
end

checkChrom = gaFuzzyHOBICCheckChromosome(newChromPair);
end

%Constructing the new chromosome
newChrom(n:n+1,:) = newChromPair;

n=n+2; %Next pair of chromosomes
end

function [newChrom] = gaFuzzyHOBICMutate(Chrom, MutOpt)
% Inputs:
%
% Chrom - vector os chromosomes (one chromosome per row)
%
% MutOpt - (optional) Vector containing mutation rate and shrink value
% MutOpt(1): MutR - number containing the mutation rate -
% probability for mutation of a variable
% MutOpt(2): MutShrink - (optional) number for shrinking the
% mutation range. See 'mutation()' function for more
% details.
% This function performs mutation in the chromssomes given in the Chrom
% vector.
%
% Output: new vector of mutated chromosomes
%
112
% REMARK: The function performs the mutation, respecting the constraints in
% the variables of the FuzzyHOBIC. For a detailed view of those
% constraints, refer to gaFuzzyHOBICPopInitialise() function.
%
% REMARK2: In this function, the mutate function is called, implementing
% the 'mutbga' algorithm, also from the University of Sheffield GA TOOLBOX
% (real-value MUTation like Breeder Genetic Algorithm).

%identifying how many chomossomes are present
[N,M] = size(Chrom);

%for each chromosome to pass through the mutation
%
% Generate the mutation based on the structure given for the FuzzyHOBIC
% chromosome
% Check if the constraints are being respected
%get Fuzzy-HOBIC limits
for n=1:N

%Part 0 - Genes 0 and 1
new_chrom_part0(n,:) = round(mutate('mutbga', Chrom(n,1:2), [0 3; 1 10], MutOpt)); %(Gene0 - 0..1;
Gene1 - 3..10)

%Part 1 - Slope - Genes 2..6 (Parameters: P2 .. P6)

%P2 > P1 (Gene 1)
P2 = round(mutate('mutbga', Chrom(n,3), [new_chrom_part0(n,2)+1; 15],MutOpt));

%P3 > P2
P3 = round(mutate('mutbga', Chrom(n,4), [P2+1; 25],MutOpt));

%P4 > P3

%P5 > P4

%P6 > P5 && P6 < 90

new_chrom_part1(n,:) = [P2 P3 P4 P5 P6];

%Part 2 - Error Percentage - Respect the constraints

%P7 > 0 && P7 < 20
P7 = round(10*mutate('mutbga', Chrom(n,8), [1; 3],MutOpt))/10; %Minimum of 1%. Maximum 3%

%P8 > P7
P8 = round(10*mutate('mutbga', Chrom(n,9), [P7+0.5; 12],MutOpt)/10);

%P9 > P8

%P10 > P9 && P10 < 100

new_chrom_part2(n,:) = [P7 P8 P9 P10];

113
%Part 3 - DeltaCtrlAction - The resolution is 0.5

%P11 > 0
P11 = round(10*mutate('mutbga', Chrom(n,12), [minDelta+0.5; 5],MutOpt))/10;

%P12 > P11
P12 = round(10*mutate('mutbga', Chrom(n,13), [P11+0.5; 8],MutOpt))/10;

%P13 > P12
P13 = round(10*mutate('mutbga', Chrom(n,14), [P12+0.5; 11],MutOpt))/10;

%P14 > P13 && P14 < 12
P14 = round(10*mutate('mutbga', Chrom(n,15), [P13+0.5; maxDelta],MutOpt))/10;

new_chrom_part3(n,:) = [P11 P12 P13 P14];
end
%Generating New chromosome vector
newChrom(:,:) = [new_chrom_part0 new_chrom_part1 new_chrom_part2 new_chrom_part3];

function [statusCheck] = gaFuzzyHOBICCheckChromosome(chrom)
% Input: vector os chromosomes (one chromosome per row)
%
% This function checks if the parameters constraints are being respected.
%
%
% Output: statusCheck(i) - 0: fail (parameters violating constraints for Chromosome i)
% 1: success (parameters respecting constraints for Chromosome i)
%Getting the number of chromosomes
[N,M] = size(chrom);

%Initialising statusCheck
statusCheck(1:N)= -1;
for i=1:N
%Verify if the constraints are being respected

%Checking Part1 - Slope
for n = 2:6
%P(n+1) > Pn
if(chrom(i,n+1) < chrom(i,n)), statusCheck(i)= 0; end
end

%Checking Part2 - ErrorPercentage
for n = 8:10
%P(n+1) > Pn
end

%Checking Part3 - DeltaCtrlAction
for n = 12:14
%P(n+1) > Pn
end
%If all the constraints are respected --> statusCheck(i) = 1
if(statusCheck(i)== -1), statusCheck(i) = 1; end
end

The HOBIC Dissertation

Uploaded by

Document Information

Original Description:

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

The HOBIC Dissertation

Uploaded by

Copyright:

Available Formats

HUMAN OPERATOR BASED INTUITIVE

You might also like