Chapter 2

Control design ideas:

a non-mathematical treatment

2.1 Initial discussion

In the previous chapter we saw that prerequisites for control design were broadly:
a defined objective, a set o f available actions and a model that could be interrogated to
establish which o f the available actions would best move the system towards meeting
the objective. Now we add more structure to the concepts to put forward a possible
design methodology (Figure 2.1). In this methodology, central use is made o f a system
model. This model is assumed able to rapidly calculate the expected behaviour o f the
system when subjected to any particular action.

set of all
real world desired
possible ~.
actions system behaviour

when the best possible action

~, has been found, it will
X ~ b ~ applied to the real system

one particular "-] ~ ] I comparison with

action is the desired behaviour
the expected
tried on the
model behaviour is
given by the model

J difference between
S behaviours
iteration is continued until the best
possible action is obtained

Figure 2.1 A possible methodologyfor control system design

12 Control theory

desired behaviour

system model
(used inversely?)
best possible
control actions

Figure 2.2 The idea of using a system model inversely to synthesise actions

Questions that immediately arise are:

• In practice can a realistic model be produced? If so how?
• By what mechanism can two sorts of behaviour be compared?
• Can the difference between desired behaviour and expected behaviour be
meaningfully used to help the iteration towards the best possible choice of action?
• How fast would the iterative procedure, involving the model, have to operate in
order for the real world system to be realistically controlled?
We answer none of these questions directly, preferring to state that Figure 2.1 remains
largely symbolic. Meanwhile we ask a further question.

2.2 Question: Can the best possible control actions be synthesised

by some mechanism?

If the system model and the desired behaviour are accurately defined should it not be
possible, in one pass, to synthesise the necessary actions shown in Figure 2.1 without
interactive searching?
This question is illustrated graphically in Figure 2.2.

2.3 Requirements for an automatic control system

If it is possible to synthesise the best possible actions continuously by some sort of

algorithm, then we have arrived at automatic control.
In the best known and simplest form of automatic control, the desired behaviour
is specified as a requirement that the measured system response (say y) should con-
tinuously and closely track a required system response (say v) that is input by the
system user (Figure 2.3).
Of course, v may be constant or even always set equal to zero. In such cases, an
automatic control system has the task of keeping a measured value of y always equal
to the specified constant value of v, despite the presence of disturbing influences.
These general requirements of an automatic control system are shown in Figure 2.4.
Moving more towards the realisation of a practical system, Figure 2.5 results.
 Control design ideas 13

v = required system response

y = measured system response

Figure 2,3 An automatic control system may be required to force the measured
response y to track a user-specified desired response as closely as
possible

disturbances w

user's
measured
required
~response y
response v
~ ( s h o u l d be equal to v)

Figure 2.4 Requirements for an automatic control system

disturbance w

', measurements of
'~ disturbance
J

i
i
I

_ ~. generator of [ system to
user's control actions / be controlled measured
required / response y
response v actions u,
algorithmically
generated

Figure 2.5 Realisation of an automatic control system

14 Control theory

It is clear that the success of the scheme presented in Figure 2.5 depends on the
disturbances w being measurable and on the existence of an accurate quantitative
understanding of the system to be controlled, for otherwise the 'generator of con-
trol actions' cannot be accurately constructed. (Notice that no use is made of any
measurement of the response.)

2.4 Automatic feedback control

Automatic feedback control overcomes both the above problems (possible unmea-
surability of disturbances, difficulty of obtaining a sufficiently accurate model) by
being error-driven as shown in Figure 2.6.

2,5 Diagrams illustrating and amplifying some of the concepts

described so far and showing relationships to a software
engineering context

(1) Control theory is interested in systems behaviour and deals with generalised
situations called systems. A system is a set of elements, interconnected by
information links and existing within a system boundary outside which is the
system environment. Figure 2.7 illustrates some of the rationale.
(2) A broad task is to go from a statement of 'desired behaviour' to the synthesis of
a system exhibiting that desired behaviour (Figure 2.8).
(3) In more specific terms, control theory is first concerned with systems under-
standing, secondly with influencing systems behaviour, and thirdly with
designing systems to exhibit particular behaviours (Figure 2.9).

w disturbances

comparator

V
+ ~ generator ~ _ _ system
of control to be
actions controlled
(controller)

~ _ _ . ~ feedback
loop

Figure 2.6 An 'error driven system ': the feedback loop

 Control design ideas 15

control theory is
interested in the behaviour
of systems

a system is any
collectionof interconnected
elements that we choose
to define

system representation

interconnections

examples of systems
human~~ ~ j domestic temperature
control system

air traffic
control system

Figure 2. 7 Some basic control ideas

desired
behaviour

synthesise
system to have
desired behaviour

Figure 2.8 The broad task of control design

Virtually every important application o f control theory is closely embedded within

a complex software engineering context. Without attempting to go into details the
following concept diagrams illustrate some o f the interactions between control design
approaches and the software context:

(4) Once systems behaviour is considered, the questions arise: what types o f
behaviour do we have in mind? How can behaviour be quantified? What factors
limit performance? (Figure 2.10).
16 Control theory

understanding the
behaviour of systems

influencing the
behaviour of systems

designing systems that

will exhibit a particular
behaviour

Figure 2.9 The sequence of objectives involved in a typical control project

How do we measure behaviour?

What sorts of behaviour do we

have in mind?

What factors set limits to

performance?

Figure 2.10 Fundamental questions related to system behaviour and system

performance

(5) Elaborating on the points in Figure 2 10, we turn to points of methodology. How
can we find out what type of system is really required? How can we turn this
knowledge into a specification and then into a design? What tools are available
to assist us? Figure 2.11 illustrates these points.
(6) Elaboration of the points in Figure 2.1l produces Figure 2.12. Here we
see a stage called 'requirement capture' dedicated to establishing what the
eventual user needs. Further stages o f systems specification, system design,
knowledge elicitation (aimed at feeding in particular expert knowledge) and
data base design precede the writing of code (i.e. programming) and the
proving, commissioning and maintenance that are essential parts o f all real
applications.
(7) Figure 2.13 is a re-run o f Figure 2.12 with a few enhancements. This figure
illustrates how a user's conception of the ideal system is modified by addi-
tional enhancements as well as by restrictions suggested by a systems designer's
expertise. The role of CASE (Computer Aided Software Engineering) tools
can be seen in the diagram. These tools allow systematic top-down design,
 Control design ideas 17

How can we find out what

'people' want from a system?

I How can we turn this knowledge

into a specification?

I How can we go from specification]

to system synthesis, i.e. to design? J

How do we test our designs

before building?

What tools do we use for

building?

Figure 2.11 The beginnings of a methodologyfor system design

requirements capture

+
system specification

+
system design,
including algorithm design

knowledge elicitation

database design

writing of code

+
proving and commissioning

t
maintenance and updating

Figure2.12 System design from requirements capture to commissioning and

maintenance
18 Control theory

user's conception system

of the ideal designer's
system expertise

en n omentsJ <
\//restrictions
J J (basedon knowledge
" of implications of
requirements certain requests)
capture

CASE tools
design •
comparison
system ~_~ system
specification specification

programming reverse
engineering

code I, I /verification

Figure 2.13 A more detailed view of system design showing the role of CASE tools
and the place of verification using reverse engineering

partitioning of work tasks into manageable parcels, continuous checks on con-

sistency and a graphical overview of the whole design project. The figure
also illustrates how so called reverse engineering is used to check that the
final codes are in complete and consistent agreement with the initial system
specification.