Specifications and Approaches
In this chapter we develop a unied framework for describing the goals of con-
troller design in terms of families of boolean design specications. We show how
various approaches, e.g., multicriterion optimization or classical optimization, can
be described in this framework.
Just as there are many di erent architectures or con gurations for control systems,
there are many di erent general approaches to expressing the design goals and
objectives for controller design. One example is the optimal controller paradigm: the
goal is to determine a controller that minimizes a single cost function or objective.
In another approach, multicriterion optimization, several di erent cost functions are
speci ed and the goal is to identify controllers that perform mutually well on these
goals. The purpose of this chapter is to develop a uni ed framework for describing
design speci cations, and to explain how these various approaches can be described
using this framework.
Throughout this chapter, we assume that a xed plant is under consideration:
the signals , , , and have been de ned, and the plant transfer matrix has
w
u
z
y
P
been determined. As described in chapter 2, the de nitions of the exogenous input
and the regulated variables should contain enough signals that we can express
w
z
every goal of the controller design in terms of , the closed-loop transfer matrix
H
from to .
w
z
3.1
Design Specifications
We begin by de ning the basic or atomic notion of a design specication:
47
48
CHAPTER 3 CONTROLLER DESIGN SPECIFICATIONS AND APPROACHES
De nition 3.1: A design speci cation is a boolean function or test on the closed-
D
loop transfer matrix .
H
Thus, for each candidate closed-loop transfer matrix , a design speci cation is
H
D
either satised or not satised: design speci cations are simple tests, with a \pass"
or \fail" outcome. A design speci cation is a predicate on transfer matrices, i.e., a
function that takes an
transfer matrix as argument and returns a boolean
n
n
z
w
result:
:
PASS, FAIL
D
H
;
!
f
g
where denotes the set of all
transfer matrices.
H
n
n
z
w
It may seem strange to the reader that we express design speci cations in terms
of the closed-loop transfer matrix instead of the controller transfer matrix ,
H
K
since we really design the controller transfer matrix , and not the resulting closed-
K
loop transfer matrix . Of course, to each candidate controller there corresponds
H
K
the resulting closed-loop transfer matrix (given by the formula (2.7) in de ni-
H
tion 2.3), which either passes or fails a given design speci cation hence, we can
think of a design speci cation as inducing a boolean test on the transfer matrices of
candidate controllers. In fact, we will sometimes abuse notation by saying \the con-
troller satis es ", meaning that the corresponding closed-loop transfer matrix
K
D
satis es .
H
D
Such a PASS/FAIL test on candidate controllers would be logically equivalent
to the design speci cation, which is a PASS/FAIL test on closed-loop transfer ma-
trices, and perhaps more natural. We will see in chapter 6, however, that there are
important geometric advantages to expressing design speci cations in terms of the
closed-loop transfer matrix and not directly in terms of the controller .
H
K
3.1.1
Some Examples
Some possible design speci cations for the standard example described in section 2.4
are:
Maximum step response overshoot. os will denote the design speci cation
D
\the step response overshoot from the reference signal to p is less than 10%".
y
Let us express os more explicitly in terms of , the 2 3 closed-loop transfer
D
H
matrix. The reference signal is the third exogenous input ( 3), and p is the
r
w
y
rst regulated variable ( 1), so 13 is the closed-loop transfer function from
z
H
the reference signal to p, and its step response is given by
y
Z
( ) = 1 1 13( )
H
j
!
j
!
t
s
t
2
e
d!
j
!
;1
3.1 DESIGN SPECIFICATIONS
49
for
0. Thus, os can be expressed as
t
D
Z
1
)
os : 1
13(
H
j
!
1 1 for all
0
j
!
t
D
2
e
d!
:
t
:
j
!
;1
Maximum RMS actuator eort. act e will denote the design speci cation:
D
\the RMS value of the actuator signal due to the sensor and process noises is
less than 0.1".
We shall see in chapters 5 and 8 that act e can be expressed as
D
Z
1
act e : 1
;
21( ) 2 proc( ) + 22( ) 2 sensor( )
0 12
D
2
jH
j
!
j
S
!
jH
j
!
j
S
!
d!
:
;1
where proc and sensor are the power spectral densities of the noises proc
S
S
n
and sensor, respectively.
n
Closed-loop stability. stable will denote the design speci cation: \the closed-
D
loop transfer matrix is achieved by a controller that stabilizes the plant".
H
(The precise meaning of stable can be found in chapter 7.)
D
A detailed understanding of these design speci cations is not necessary in this
chapter the important point here is that given any 2 3 transfer matrix , each
H
of the design speci cations os, act e , and stable is either true or false. This
D
D
D
is independent of our knowing how to verify whether a design speci cation holds
or not for a given transfer matrix. For example, the reader may not yet know of
any explicit procedure for determining whether a transfer matrix satis es stable
H
D
nevertheless it is a valid design speci cation.
These design speci cations should be contrasted with the associated informal
design goals \the step response from the reference signal to p should not overshoot
y
too much" and \the sensor and process noises should not cause to be too large".
u
These are not design speci cations, even though these qualitative goals may better
capture the designer's intentions than the precise design speci cations os and
D
act e . Later in this chapter we will discuss how these informal design goals can
D
be better expressed using families of design speci cations.
3.1.2
Comparing and Ordering Design Specifications
In some cases, design speci cations can be compared. We say that design speci-
cation 1 is tighter or stronger than 2 (or, 2 is looser or weaker than 1) if
D
D
D
D
all transfer matrices that satisfy 1 also satisfy 2. We will say that 1 is strictly
D
D
D
tighter or strictly stronger than 2 if it is tighter and in addition there is a transfer
D
matrix that satis es 2 but not 1.
D
D
An obvious but extremely important fact is that given two design speci cations,
it is not always possible to compare them: it is possible that neither is a stronger
50
CHAPTER 3 CONTROLLER DESIGN SPECIFICATIONS AND APPROACHES
speci cation. The ordering of design speci cations by strength is a partial ordering,
not a linear or total ordering. We can draw a directed graph of the relations between
di erent speci cations by connecting strictly weaker speci cations to stronger ones
by arrows, and deleting the arrows that follow from transitivity (i.e., 1 is stronger
D
than 2 which is stronger than 3 implies 1 is stronger than 3). An example
D
D
D
D
of a linear ordering is shown in gure 3.1(a): every pair of speci cations can be
compared since there is a directed path connecting any two speci cations. By
comparison, a partial but not linear ordering of design speci cations is shown in
gure 3.1(b). Speci cation D is tighter than C, which in turn is tighter than
D
D
both A and B. Similarly, speci cation G is tighter than E, which is itself
D
D
D
D
tighter than C. However, speci cations E and D cannot be compared nor can
D
D
D
the design speci cations G and D.
D
D
r
r
r
D
D
D
A
A
B
r
r
D
D
B
C
r
r
r
D
D
D
C
D
E
r
r
r
D
D
D
D
F
G
( )
( )
a
b
In these directed graphs each node represents a specication.
Figure
3.1
Arrows connect a weaker specication to a tighter one. The graph in (a)
shows a linear ordering: all specications can be compared. The graph
in (b) shows a partial, but not linear, ordering: some specications can
be compared (e.g.,
is tighter than ), but others cannot (e.g.,
is
D
D
D
D
A
F
neither weaker nor tighter than ).
D
D
We may form new design speci cations from other design speci cations using
any boolean operation, for example conjunction, meaning joint satisfaction:
1
2 :
satis es 1 and 2
D
^
D
H
D
D
:
The new design speci cation 1
2 is tighter than both 1 and 2.
D
^
D
D
D
We say that a design speci cation is infeasible or inconsistent if it is not satis ed
by any transfer matrix it is feasible or consistent if it is satis ed by at least one
transfer matrix. We say that the set of design speci cations 1 ...
is jointly
fD
D
g
L
infeasible or jointly inconsistent if the conjunction 1
is infeasible if the
D
^
^
D
L
conjunction 1
is feasible, then we say that the set of design speci cations
D
^
^
D
L
1 ...
is jointly feasible or achievable.
fD
D
g
L
3.2 THE FEASIBILITY PROBLEM
51
3.2
The Feasibility Problem
Given a speci c set of design speci cations, we can pose the feasibility problem of
determining whether all of our design speci cations can be simultaneously satis ed:
De nition 3.2: Feasibility controller design problem: given a set of design speci-
cations 1 ...
, determine whether it is jointly feasible. If so, nd a closed-
fD
D
g
L
loop transfer matrix that meets the design specications 1 ...
.
H
D
D
L
Like design speci cations, the feasibility problem has a boolean outcome. If this
outcome is negative, we say the set of design speci cations 1 ...
is too tight,
fD
D
g
L
infeasible, or unachievable if the outcome of the feasibility problem is positive, we
say that 1 ...
is achievable or feasible. It is only for ease of interpretation
fD
D
g
L
that we pose the feasibility problem in terms of sets of design speci cations, since
it is equivalent to feasibility of the single design speci cation 1
.
D
^
^
D
L
The feasibility problem is not meant by itself to capture the whole controller
design problem rather it is meant to be a basic or atomic problem that we can
use to describe other, more subtle, formulations of the controller design problem.
In the rest of this chapter we will describe various design approaches in terms of
families of feasibility problems. This is exactly like our de nition of the standard
plant, which is meant to be a standard form in which to describe the many possible
architectures for controllers. The motivation is the same|to provide the means to
sensibly compare apparently di erent formulations.
3.3
Families of Design Specifications
A single xed set of design speci cations usually does not adequately capture the no-
tion of \suitable" or \satisfactory" system performance, which more often involves
tradeo s among competing desirable qualities, and speci cations with varying de-
grees of hardness. Hardness is a quality that describes how rmly the designer
insists on a speci cation, or how exible the designer is in accepting violations of
a design speci cation. Thus, the solution of a single, xed, feasibility problem may
be of limited utility. These vaguer notions of satisfactory performance can be mod-
eled by considering families of related feasibility problems. The designer can then
choose among those sets of design speci cations that are achievable.
To motivate this idea, we consider again the speci cations described in sec-
tion 3.1.1. Suppose rst that the solution to the feasibility problem with the set of
speci cations os act e
stable is a rmative, and that
simultaneously sat-
fD
D
D
g
H
is es os, act e , and stable. If the set of speci cations os act e
stable ad-
D
D
D
fD
D
D
g
equately captures our notion of a satisfactory design, then we are done. But the de-
signer may wonder how much smaller the overshoot and actuator e ort can be made
than the original limits of 10% and 0.1, respectively. In other words, the designer
will often want to know not just that the set of speci cations os act e
stable
fD
D
D
g
52
CHAPTER 3 CONTROLLER DESIGN SPECIFICATIONS AND APPROACHES
is achievable, but in addition how much these speci cations could be tightened while
remaining achievable.
A similar situation occurs if the solution to the feasibility problem with the
design speci cations os act e
stable is negative. In this case the designer
fD
D
D
g
might like to know how \close" this set of design speci cations is to achievable. For
example, how much larger would the limit on overshoot have to be made for this
set of design speci cations to be achievable?
Questions of this sort can be answered by considering families of design spec-
ications, which are often indexed by numbers. In our example above, we could
consider a family of overshoot speci cations indexed, or parametrized, by the al-
lowable overshoot. For 1 0 we de ne
a
( )
a
to
1
os
: overshoot of step response from
p
1%
D
r
y
a
:
Note that ( )
a
1
os is a dierent specication for each value of 1. Similarly, a family
D
a
of actuator e ort speci cations for 2 0 is
a
( )
a
2
act e : RMS deviation of due to the sensor and actuator noises
2
D
u
a
:
Thus for each 1 0 and 2 0 we have a di erent set of design speci cations,
a
a
(
)
( )
( )
a
2
a
a
= a
1
2
1
os
act e
stable
D
D
^
D
^
D
:
Suppose we solve the feasibility problem with design speci cations (
) for
a
a
1
2
D
each 1 and 2, shading the area in the ( 1 2) plane corresponding to feasible
a
a
a
a
(
), as shown in gure 3.2. We call the shaded region in gure 3.2, with some
a
a
1
2
D
abuse of notation, a plot of achievable specications in performance space.
From this plot we can better answer the vague questions posed above. Our
original set of design speci cations corresponds to 1 = 10% and 2 = 0 1, shown
a
a
:
as X in gure 3.2. From gure 3.2 we may conclude, for example, that we may
D
tighten the overshoot speci cation to 1 = 6% and still have an achievable set
a
of design speci cations ( Y in gure 3.2), but if we further tighten the overshoot
D
speci cation to 1 = 4%, we have a set of speci cations ( Z) that is too tight.
a
D
Alternatively, we could tighten the actuator e ort speci cation to 2 = 0 06 and
a
:
also have an achievable set of design speci cations ( W).
D
By considering the feasibility problem for families of design speci cations, we
have considerably more information than if we only consider one xed set of speci -
cations, and therefore are much better able to decide what a satisfactory design is.