System Architecture
In this chapter we describe a formal framework for what we described in chapter 1
as the system to be controlled, the control conguration, and the control law or
controller.
2.1
Terminology and Definitions
We start with a mathematical model of the system to be controlled that includes
the sensors and actuators. We refer to the independent variables in this model as
the input signals or inputs, and the dependent variables as the output signals or
outputs. In this section we describe an important further division of these signals
into those the controller can access and those it cannot.
The inputs to the model include the actuator signals, which come from the
controller, and other signals that represent noises and disturbances acting on the
system. We will see in chapter 10 that it may be advantageous to include among
these input signals some ctitious inputs. These ctitious inputs are not used to
model any speci c noise or disturbance they allow us to ask the question, \what if
a signal were injected here?".
De nition 2.1: The inputs to the model are divided into two vector signals:
The actuator signal vector, denoted u, consists of the inputs to the model that
can be manipulated by the controller. The actuator signal vector u is exactly
the signal vector generated by the control processor.
The exogenous input vector, denoted w, consists of all other input signals to
the model.
25
26
CHAPTER 2 A FRAMEWORK FOR CONTROL SYSTEM ARCHITECTURE
The number of actuator and exogenous input signals, i.e., the sizes of u and w,
will be denoted n and n , respectively.
u
w
Our model of the system must provide as output every signal that we care about,
i.e., every signal needed to determine whether a proposed controller is an acceptable
design. These signals include the signals we are trying to regulate or control, all
actuator signals (u), all sensor signals, and perhaps important internal variables,
for example stresses on various parts of a mechanical system.
De nition 2.2: The outputs of the model consist of two vector signals:
The sensor signal vector, denoted y, consists of output signals that are acces-
sible to the controller. The sensor signal y is exactly the input signal vector
to the control processor.
The regulated outputs signal vector, denoted z, consists of every output signal
from the model.
The number of sensor and regulated output signals, i.e., the sizes of y and z,
will be denoted n and n , respectively.
y
z
We refer to the model of the system, with the two vector input signals w and u
and the two vector output signals z and y, as the plant, shown in gure 2.1. Even
though z includes the sensor signal y, we draw them as two separate signal vectors.
exogenous inputs
regulated outputs
w
z
Plant
actuator inputs
sensed outputs
u
y
The plant inputs are partitioned into signals manipulable by
Figure
2.1
the controller ( ) and signals not manipulable by the controller ( ). Among
u
w
all of the plant outputs ( ) are the outputs that the controller has access to
z
( ).
y
When the control system is operating, the controller processes the sensor signal y
to produce the actuator signal u, as shown in gure 2.2. We refer to this connection
of the plant and controller as the closed-loop system. The closed-loop system has
input w and output z.
2.1.1
Comparison to the Classical Plant
Our notion of the plant di ers from that used in classical control texts in several
ways. First, our plant includes information about which signals are accessible to
the controller, whereas in classical control, this is often side information given along
with the classical plant in the controller design problem. For example, what would
2.1 TERMINOLOGY AND DEFINITIONS
27
exogenous inputs
regulated outputs
w
z
Plant
actuator inputs
sensed outputs
u
y
Controller
The closed-loop system. The controller processes the sensed
Figure
2.2
signals to produce the actuator signals.
be called a \state-feedback" control system and an \output feedback" control system
for a given classical plant, we describe as closed-loop systems for two dierent plants,
since the sensed signals (our y) di er in the two systems. Similarly, the distinction
made in classical control between one degree-of-freedom and two degree-of-freedom
control systems is expressed in our framework as a di erence in plants.
Second, our plant includes information about where exogenous commands such
as disturbances and noises enter the system. This information is also given as side
information in classical control problems, if it is given at all. In classical control, the
disturbances might be indicated in a block diagram showing where they enter the
system some important exogenous inputs and regulated variables are commonly left
out, since it is expected that the designer will intuitively know that an acceptable
design cannot excessively amplify, say, sensor noise.
Similarly, our plant makes the signal z explicit|the idea is that z contains every
signal that is important to us. In classical control texts we nd extensive discussion
of critical signals such as actuator signals and tracking errors, but no attempt is
made to list all of the critical signals for a given problem.
If w and z contain every signal about which we will express a constraint or
speci cation, then candidate closed-loop systems can be evaluated by simulations
or tests involving only the signals w and z. Thus, speci cations (in the sense of a
contract) for the control system could be written in terms of w and z only.
We believe that the task of de ning the signals u, w, y, and z for a system to
be controlled is itself useful. It will help in forming sensible speci cations for a
controller to be designed and it helps in identifying the simulations that should be
done to evaluate a candidate controller.
28
CHAPTER 2 A FRAMEWORK FOR CONTROL SYSTEM ARCHITECTURE
2.1.2
Command Inputs and Diagnostic Outputs
The reader may have noticed that command signals entering the controller and diag-
nostic signals produced by the controller do not appear explicitly in gure 2.2, even
though they do in gures 1.1 and 2.3. In this section we show how these operator
interface signals are treated in our framework. Our treatment of command signals
simply follows the de nitions above: if the command signal is directly accessible to
the controller, then it is included in the signal y. There remains the question of how
the command signals enter the plant. Again, we follow the de nitions above: the
command signals are plant inputs, not manipulable by the controller (they are pre-
sumably manipulable by some external agent issuing the commands), and so they
must be exogenous inputs, and therefore included in w. Often, exogenous inputs
that are commands pass directly through the plant to some of the components of
y, as shown in gure 2.4. Diagnostic outputs are treated in a similar way.
wsystem
zsystem
System
usystem
ysystem
Controller
diagnostic
command
outputs
inputs
The controller may accept command signals as inputs and
Figure
2.3
produce diagnostic and warning signals as outputs (see gure 1.1). This is
described in our framework by including the command signals in and ,
w
y
and the diagnostic and warning signals in and , as shown in gure 2.4.
u
z
2.2
Assumptions
In this book we make the following assumptions:
Assumption 2.1: The signals w, u, z, and y are real vector-valued continuous-
time signals, i.e., functions from a real, nonnegative time variable into the appro-
priately dimensioned vector space:
w : R+ R
R
R
R
n
u : R
n
z : R
n
y : R
n
:
w
+
u
+
z
+
y
!
!
!
!
2.2 ASSUMPTIONS
29
Plant
wsystem
w n
o
w
zsystem
commands
System
zdiag
z
un
o
y
usystem
y
Controller
system
udiag
ycommands
In our framework the command signals are included in and
Figure
2.4
w
pass through the plant to , so that the controller has access to them.
y
Similarly, diagnostic signals produced by the controller are included in ,u
and pass through the plant to .z
Assumption 2.2: The plant is linear and time-invariant (LTI) and lumped, i.e.,
described by a set of constant coecient linear dierential equations with zero initial
conditions.
Assumption 2.3: The controller is also LTI and lumped.
The di erential equations referred to will be described in detail in section 2.5.
2.2.1
Some Comments
About assumption 2.2:
Many important plants are highly nonlinear, e.g., mechanical systems that
undergo large motions.
Assumption 2.2 is always an approximation, only good for certain ranges of
values of system signals, over certain time intervals or frequency ranges, and
so on.
About assumption 2.3:
Even if the plant is LTI, it is still a restriction for the controller to be LTI.
We have already noted that control systems that use digital control processors
process sampled signals. These controllers are linear, but time-varying.
30
CHAPTER 2 A FRAMEWORK FOR CONTROL SYSTEM ARCHITECTURE
We wish to emphasize that our restriction to LTI plants and controllers is hardly
a minor restriction, even if it is a commonly made one. Nevertheless, we believe the
material of this book is still of great value, for several reasons:
Many nonlinear plants are well modeled as LTI systems, especially in regulator
applications, where the goal is to keep the system state near some operating
point.
A controller that is designed on the basis of an approximate linear model of
a nonlinear plant often works well with the nonlinear plant, even if the linear
model of the plant is not particularly accurate. (See the Notes and References
at the end of this chapter.)
Some of the e ects of plant nonlinearities can be accounted for in the frame-
work of an LTI plant and controller. (See chapter 10.)
Linear control systems often form the core or basis of control systems designed
for nonlinear systems, for example in gain-scheduled or adaptive control sys-
tems. (See the Notes and References at the end of this chapter.)
A new approach to the control of nonlinear plants, called feedback lineariza-
tion, has recently been developed. If feedback linearization is successful, it
reduces the controller design problem for a nonlinear plant to one for which
assumption 2.2 holds. (See the Notes and References at the end of this chap-
ter.)
Even when the nal controller is time-varying (e.g., when implemented on
a digital control processor), a preliminary design or analysis of achievable
performance is usually carried out under the assumption 2.3. This design or
analysis then helps the designer select appropriate sample rates.
The results of this book can be extended to cover linear time-varying plants
and controllers, in particular, the design of single-rate or multi-rate digital
controllers. (See chapter 16.)
2.2.2
Transfer Matrix Notation
We will now brie y review standard notation for LTI systems. Consider an LTI
system with a single (scalar) input a and a single (scalar) output b. Such a system
is completely described by its transfer function, say G, so that
B(s) = G(s)A(s)
(2.1)
2.2 ASSUMPTIONS
31
where A and B are the Laplace transforms of the signals a and b respectively:
A
Z
(s) = 1 a(t)e dt
;st
0
B
Z
(s) = 1 b(t)e dt:
;st
0
Equivalently, the signals a and b are related by convolution,
b
Z
(t) = t g( )a(t )d
(2.2)
0
;
where g is the impulse response of the linear system,
G
Z
(s) = 1 g(t)e dt:
;st
0
We will write (2.1) and (2.2) as
b = Ga:
(2.3)
We will also use the symbol G to denote both the transfer function of the LTI
system, and the LTI system itself. An interpretation of (2.3) is that the LTI system
G acts on the input signal a to produce the output signal b. We say that G is the
transfer function from a to b.
Identical notation is used for systems with multiple inputs and outputs. For
example, suppose that an LTI system has n inputs and m outputs. We collect the
scalar input signals a1 ... a to form a vector input signal a,
n
2
a1(t) 3
a(t) =
.
6
.. 7
4
5
a (t)
n
and similarly, we collect the output signals to form the vector signal b. The system
is completely characterized by its transfer matrix, say G, which is an m n matrix
of transfer functions. All of the previous notation is used to represent the multiple-
input, multiple-output (MIMO) system G and its vector input signal a and vector
output signal b.
2.2.3
Transfer Matrix Representations
A consequence of assumption 2.2 is that the plant can be represented by a transfer
matrix P, with a vector input consisting of the vector signals w and u, and a
vector output consisting of the vector signals z and y. Similarly, a consequence of
assumption 2.3 is that the controller can be represented by a transfer matrix K,
32
CHAPTER 2 A FRAMEWORK FOR CONTROL SYSTEM ARCHITECTURE
with a vector input y and vector output u. We partition the plant transfer matrix
P as
P = P
P
z
w
z
u
P
P
y
w
y
u
so thatz=P w+P u
(2.4)
z
w
z
u
y = P w + P u:
(2.5)
y
w
y
u
Thus, P is the transfer matrix from w to z, P is the transfer matrix from u
z
w
z
u
to z, P is the transfer matrix from w to y, and P is the transfer matrix from u
y
w
y
u
to y. This decomposition is shown in gure 2.5. We will emphasize this partitioning
of the plant with dark lines:
P = P
P
z
w
z
u
P
P
:
y
w
y
u
exogenous inputs
+
q
r
regulated outputs
w
P
z
z
w
+
Pyw
Pzu
actuator inputs
+
q
r
sensor outputs
y
u
Pyu
+
The decomposed LTI plant.
Figure
2.5
Now suppose the controller is operating, so that in addition to (2.4{2.5) we have
u = Ky:
(2.6)
We can solve for z in terms of w to get
z = ;P + P K(I P K) 1P w
;
;
z
w
z
u
y
u
y
w
provided det(I P K) is not identically zero, a well-posedness condition that we
;
y
u
will always assume.
2.2 ASSUMPTIONS
33
De nition 2.3: The closed-loop transfer matrix H is the transfer matrix from w
to z, with the controller K connected to the plant P:
H = P + P K(I P K) 1P :
;
(2.7)
;
z
w
z
u
y
u
y
w
Thus
z = Hw:
(2.8)
The entries of the transfer matrix H are the closed-loop transfer functions from
each exogenous input to each regulated variable. These entries might represent, for
example, closed-loop transfer functions from some disturbance to some actuator,
some sensor noise to some internal variable, or some command signal to some ac-
tuator signal. The formula (2.7) above shows exactly how each of these closed-loop
transfer functions depends on the controller K.
A central theme of this book is that H should contain every closed-loop transfer
function of interest to us. Indeed, we can arrange for any particular closed-loop
transfer function in our system to appear in H, as follows. Consider the closed-loop
system in gure 2.6 with two signals A and B which are internal to the plant. If our
interest is the transfer function from a signal injected at point A to the signal at
point B, we need only make sure that one of the exogenous signals injects at A, and
that the signal at point B is one of our regulated variables, as shown in gure 2.7.
w
z
B
u
A
y
P
K
Two signals A and B inside the plant .
Figure
2.6
P
34
CHAPTER 2 A FRAMEWORK FOR CONTROL SYSTEM ARCHITECTURE
w n
o
q
z
B
+
r
u
+ A
y
P
K
Accessing internal signals A and B from and .
Figure
2.7
w
z
2.3
Some Standard Examples from Classical Control
In this section we present various examples to illustrate the concepts introduced
in this chapter. We will also de ne some classical control structures that we will
periodical y refer to.
2.3.1
The Classical Regulator
In this section we consider the classical single-actuator, single-sensor (SASS) reg-
ulator system. A conventional block diagram is shown in gure 2.8. We use the
symbol P0 to denote the transfer function of the classical plant. The negative sign
at the summing junction re ects the classical convention that feedback should be
\negative".
+
e
u
yp
;
0