Control Loop Performance Analysis Over Networked Control Systems
Control Loop Performance Analysis Over Networked Control Systems
Control Loop Performance Analysis Over Networked Control Systems
a
s
sc
ca
Unsuccessfully transmitted or large and unpredicted time-
delayed messages may deteriorate the control system
performance, even causing a critical failure in the system.
This fact motivates the use of communication networks
where the medium access control protocol is able to
schedule messages according to their real-time
requirements, guaranteeing bounded transmissions.
Several protocols that meet these requirements have been
proposed for control systems [9]. Typically, guaranteed
bounded transmission can be achieved by non-destructive
random access networks (e.g., CAN [2]) or by
deterministic medium access schemes, such as token-
passing based networks (e.g., Profibus [8]).
The analysis and design of closed-loop systems occupy
a fundamental role in control theory. The standard
mathematical models for computer-controlled systems
transform a continuous-time system into a discrete-time
system by considering the behaviour of the signals
(manipulated and controlled signals) just at the sampling
instants. In consequence computers for control applications
are expected to behave as the mathematical models
demand. The control community sees the computing
platform, i.e., NCSs, as providing the determinism that
discrete-time control theory requires. Control theory has
considered implementations other than dedicated
processors systems only to a very small extent.
Consequently, when computing resources (processor time
and communication bandwidth) are limited, control theory
rarely advises on how to design controllers to take these
limitations into account.
B. Problems in NCS
In the implementation of control loops over NCS, we
identify the following main problems:
Time delays: distributed computing architectures
introduce various forms of delays in control loops:
communication and computational delays.
Communication delays occur when processors (such as
sensors, controllers and actuators) exchange data
through the shared communication media.
Computational delays appear because processors take
time in processing the data.
Data consistency: network packet drops occasionally
happen on an NCS when, for example, there are node
failures or message collisions. Consequently,
distributed architectures may introduce a lack of data
consistency between the different processors, implying
that control applications may be taking decisions
according to wrong data.
There are two main approaches for accommodating all
of these problematic issues in the design of control loops
over NCSs. An approach is to design the control system
regardless of delays or packets drops, but ensuring that the
communication mechanisms (e.g., message scheduling or
recovering and retransmission procedures) will minimize
the likelihood of these events. The other approach is to
treat the network characteristics as design specifications
for control applications. That is, to take into account,
delays and packets drops in the controller design stage.
To start dealing with this problem, we focused our study
following the second approach, that is, in strategies that
take into account network properties in the controller
design stage. Specifically, in this paper, we focus in time
delay effects.
III. DISTRIBUTED CONTROL LOOPS TIMING
In control loops closed over NCSs, data (manipulated
and controlled variables) is sent and received by network
nodes. Specifically, for a control loop, the main processing
activities that occur at each control loop execution, which
can be schematically seen in Figure 1, are:
The sensor node samples the process output with a
constant sampling period h, activity that includes the
Analog-to-Digital (AD) conversion and codification
and packing of the message to be sent to the controller.
The time taken for these activities introduces a
sampling computational delay
s
.
The controlled variables are sent to the controller node,
introducing a communication delay
sc
.
The controller node, upon message reception, unpacks
and decodes the message, and using a control algorithm
calculates the control signals to be sent to the actuator
node, and prepares, codifies and packs a new message,
introducing a control algorithm computational delay
c
.
The control signals are sent to the actuator node,
introducing a new communication delay
ca
.
The actuator node, upon message reception, obtains the
manipulated signals, that after the Digital-to-Analog
(DA) conversion, are applied to the process,
introducing a new actuator computational delay
a
.
Fig. 1. Closed loop processing activities
The accumulation of all distributed architecture induced
delays, called sampling-actuation delay, is given by (1).
k
=
s
(k) +
sc
(k) +
c
(k) +
ca
(k) +
a
(k) (1)
Where k denotes the k
th
control loop execution. Note that
k
, in general, cannot be considered to be constant.
Network induced delays (
sc
and
ca
) may vary depending
on the network traffic, medium access protocol, and the
chosen hardware. Computational induced delays (
s
,
c
,
a
)
may vary depending on the processing nodes load,
scheduling, etc. However, since we are interested on
evaluating the effects of communication-induced delays in
the performance of control loops closed over
communication networks, henceforth we assume that the
computational delays are constant. Note that this
) ( ) , (
) ( ) , ( ) ( ) ( ) (
1
0
h kh u h
kh u h kh x h h kh x
+
+ = +
Ah
e h = ) (
B ds e h
h
As
0
0
) , (
B ds e e h
As h A
0
) (
1
) , (
) ( ) ( ) ( kh Du kh Cx kh y + =
) ( ) (
) (
+ = t Bu t Ax
dt
t dx
) ( ) ( ) ( t Du t Cx t y + =
) ( ) , ( ) ( kh x h L kh u =
) ( ) (
) (
t Bu t Ax
dt
t dx
+ =
) ( ) ( ) ( t Du t Cx t y + =
) ( ) ( ) ( ) ( ) ( kh u h kh x h h kh x + = +
) ( ) ( ) ( kh Du kh Cx kh y + =
Ah
e h = ) (
B ds e h
h
As
=
0
) (
) ( ) ( ) ( kh x h L kh u =
assumption is a realistic assumption:
s
and
a
(AD and DA
conversions) can be regarded as negligible, compare to the
communication delays. In addition,
c
can be considered
constant if we assume that the control algorithm is
executing in a dedicated processor.
IV. SUITABILITY OF TRADITIONAL CONTROL
METHODS
In this section we discuss the suitability of a standard
discrete-time control model and methods for analysis and
design of control loops implemented over NCS.
The continuous-time state-space model of a linear time-
invariant system can be described by the following
standard form (2) and (3):
(2)
(3)
Traditional discrete-time control theory assumes that
when transferring such continuous-time models to a
discrete form, the resulting controller (in the form of an
algorithm) will execute in dedicated processors and
processors are assumed to be fast and deterministic enough
to not worry about the timing costs that the controlling
activities may have in the implementation. That is, the
computing platform for control applications is expected to
behave as the discrete-time mathematical models demand.
However, as we have seen in section III, control loops
distributed over NCSs are subjected to the implementation
induced time delays (specifically, communication time
delays). In the following, we discuss traditional discrete-
time control models with respect to time delays.
A. Instantaneous execution
The most classical model for discrete-time control
systems assumes that the control algorithm is executed
instantaneously at every sampling period h. Consequently,
equidistant sampling and actuation is assumed.
Based on these assumptions, for periodic sampling with
constant period h, the discrete-time system can be
described by (4) and (5), where and are obtained from
(2) and (3) as detailed in (6) and (7)
(4)
(5)
(6)
(7)
Using classical controller design methods such as pole
placement or optimization approaches, the control loop can
be closed by state feedback, as detailed in (8). Equation (8)
gives the state feedback control law, where L is the gain
matrix.
(8)
It is known that discrete-time control systems specified
by (4), (5) and (8) behaves correctly when the computing
platform introduces delays that are negligible compared to
the system dynamics. This is the case of most control loops
implemented in dedicated processors. However, for
distributed control loops (as those in Figure 1) the
communication-induced delays may not be negligible
compared to the system dynamics. In those cases, the
expected behaviour of systems specified by (4), (5) and (8)
may change, in the sense that their performance may
seriously decrease, even causing instability. To avoid this
undesired closed loop system behaviour, such delays may
be included in the discrete-time control design model.
B. Constant Delay
The simplest model is given by discrete-time control
models obtained from continuous-time models that include
a constant time delay in their mathematical formulation.
A state-space model for the continuous time invariant
system including a constant delay can be described by (9)
and (10) [10].
(9)
(10)
where the time delay is assumed lower than the sampling
period. The corresponding discrete time form is given by
(11) and (12), with the continuous-to-discrete
transformations detailed in (13), (14) and (15).
(11)
(12)
(13)
(14)
(15)
As before, state feedback can be used to close the loop,
given by (16).
(16)
Note that each closed loop system specified by (11),
(12) and (16) depends on a constant sampling period (h)
and on a constant time delay ().
Although those systems can cope with time delays, if the
latter vary, the model fails and it is no longer appropriated.
That is, if the computing platform introduces varying time
delays (e.g., communication jitters in the delays), the
performances of those systems decrease.
C. Varying Delays
Network delays are typically varying delays. That is, the
sampling-actuation delays will vary at each control loop
execution (recall equation (1) in section III).
Therefore, the control design strategy must take into
account this variation. What we know is that this variation
will be limited, that is,
k
will take values within a known
) ( ) , (
) ( ) , ( ) ( ) ( ) (
1
0
h kh u h
kh u h kh x h h kh x
k
k
+
+ = +
Ah
e h = ) (
B ds e h
k
h
As
k
0
0
) , (
B ds e e h
k
k
As h A
k
0
) (
1
) , (
) ( ) ( ) ( kh Du kh Cx kh y + =
) ( ) , ( ) ( kh x h L kh u
k
=
discrete range, which can be determined at the design stage
according to the network characteristics (according to the
worst-case message latency) if we assume a discrete-time
model and a global time for clock synchronization in the
distributed architecture [3].
Knowing those delays, the mathematical discrete-time
control model for systems with varying time delays
specified in (17) and (18), including state feedback (19),
with the corresponding continuous-to-discrete transforma-
tions detailed in (20), (21) and (22) can be used [6].
(17)
(18)
(19)
(20)
(21)
(22)
Note that each closed loop system, specified by (17),
(18) and (19), depend on a constant sampling period h and
on varying time delay
k
.
However, even if the system still holds for time-varying
delays, another problem arises: information availability.
Systems specified by (17), (18) and (19) mandate that the
sampling period and time delays must be known at the
beginning of each controller execution.
V. CONTROL LOOP TOPOLOGIES
In order to meet the implementation timing constraint
posed by systems specified by (17), (18) and (19), we need
to look at the specific distributed control loop topology.
That is, we have to know whether at the beginning of each
controller execution the sampling period h, and time delay
(sampling-actuation delay)
k
, can be known.
The sampling period is chosen at the design stage, and,
since in our architecture we assumed that the sensor node
is performing strictly periodic sampling, h is known and
constant. However, the varying communication delays may
not be completely known at the beginning of each
controller execution. It usually will depend on the specific
NCS topology.
Networks nodes that are of specific interest for control
loops over NCSs are sensor, actuator and controller nodes.
In table 1 we provide the most representative topologies
concerning those nodes. In the following, for each
topology we derive the communication delays that can
appear and we assest the suitability of the presented
discrete-time control models (section IV):
Case 1: the system is free of communication delays,
and if the computing delays are negligible with respect
to the dynamics of the system, the standard models
from linear time-invariant discrete-time systems ((4),
(5) and (8)) can be applied.
Case 2: the system is characterized by the sensor to
controller varying time delay,
sc
. Although varying, it
can be known (for example using time-stamping
techniques) at the beginning of each controller
execution. Therefore, the mathematical model given by
(17), (18), and (19) is feasible, as we showed in [6].
Case 3: the system is characterized by the controller to
actuator delay varying time delay,
ca
. Unfortunately, it
can not be known at the beginning of each controller
execution, because this delay takes place after the
controller execution. In addition, due to the fact that
this time delay may vary, none of the previous discrete-
time control models can be used.
Case 4: this is the more general and realistic case.
Although sensor to controller delays can be know (as in
Case 2), similarly to Case 3, the controller to actuator
delays preclude the suitability of any of the previous
discrete-time control models.
TABLE 1. DISTRIBUTED CONTROL LOOPS TOPOLOGIES
Case Sketch Delay ()
1
= 0
2
=
sc
3
=
ca
4
=
sc
+
ca
An approach to overcome the problems posed by Cases
3 and 4 is to model the communication delays as
probabilistic distributions and to design the controller to
account for them. For example, [7] present various
probabilistic communication delays models and
accordingly, solves an LQG optimal control problem for
them. Nevertheless, although considering communication
delays by means of probability functions is a first
approximation, further research is needed.
Another approach to solve Cases 3 and 4 is to assume a
constant sampling-actuation delay, forcing a synchronous
actuation (synchronous with respect the sampling), thus
being able to apply the discrete-time control model given
by (11), (12) and (16). This can be achieved by forcing the
actuation to occur at equidistant times, given by the worst-
case-message-latency. However, this may unnecessarily
impose a longer time delay than the actual ones that appear
during system runtime, thus forcing a pessimistic timing
behavior in the closed loop system that may result in a
graceful but unnecessarily system performance
degradation. In next section we further discuss this issue.
VI. SYNCHRONOUS vs. ASYNCHRONOUS
ACTUATION: SIMULATION RESULTS
As we introduced in the previous section, from the point
of view of the actuation, we can have synchronous and
asynchronous actuation, which depends of the sampling-
actuation delay characteristics. In control loops over NCSs,
if the time elapsed from sampling to actuation is constant,
S C A
S C A
A S C
A S C
we call the actuation to be synchronous. Otherwise, we call
it to be asynchronous.
Consequently, although communication delays may
vary, we can force a synchronous or asynchronous
actuation in our system. A synchronous actuation can be
achieved by delaying at each control loop execution the
actuation (for example, according to the worst-case-
message-latency guaranteed by the relying network) such
as each sampling-actuation delay is constant. In addition,
for these cases, we can use the discrete-time control model
given by (11), (12) and (16), solving the problems posed
by cases 3 and 4. An asynchronous actuation will occur if
each actuation is performed as soon as the control signals
are received in the actuator node. However, as we pointed
out in the previous section, control theory lacks of suitable
control models for this case.
Nevertheless, it is important to mention that when the
actuation is synchronous, we are assuming the worst-case-
message-latency, thus assuming a longer time delay than
the actual ones which implies to allow an unnecessarily
degradation in the system. To illustrate this problem, lets
assume that the discrete-time control model given by (17),
(18) and (19), that is based on the assumption of
asynchronous actuation, knows the varying time delays
that apply at run time (recall that this is not a realistic
assumption; however, we take this assumption to compare
and evaluate the performance of systems with synchronous
or asynchronous actuation).
The set-up that we use for this performance evaluation is
an inverted pendulum [7]. The performance loss criterion
we present to evaluate the performance of systems with
synchronous and asynchronous actuation is (23)
(23)
where y
nom
is the nominal system response (obtained when
the controlled system assuming constant nominal sampling
period with constant nominal time delay), which is used as
a reference and y
act
is the actual system response.
To evaluate the inverted pendulum response assuming
the two control schemes (one with synchronous actuation
and one with asynchronous actuation), we consider:
a) Applying the model given by (17), (18) and (19),
where the varying sampling-actuation delays, which
we suppose to be known at each closed loop
execution, randomly vary from 20ms to 80 ms.
b) Applying the model given by (11), (12) and (16), with
a constant sampling-actuation delay of 80 ms, which is
the longest sampling-actuation delay that can appear
in case a).
Fig.2. Performance evaluation
In all the cases, the nominal response for the
performance loss criteria is obtained by a model given by
(11), (12) and (16), with a constant sampling-actuation
delay of 20ms. The sampling period is also constant in all
the cases.
Figure 2 shows the performance evaluation results. It
shows the evaluation for case b) constant delay (80ms) -
and 10 series that correspond to the performance loss for
case a). Notice in Figure 2, that the performance loss of the
inverted pendulum response of the cases with varying
sampling-actuation delays is always smaller than the case
with constant but longer sampling-actuation delay.
Consequently, we can conclude that, for the inverted
pendulum example, the performance of the control loop on
NCS to compensate for varying delays (asynchronous
actuation) is better than compensating for a constant but
longer delay (synchronous actuation).
VI. TOWARDS ASYNCRHONOUS MODELS
In this section, we present an ad-hoc technique that can
be used to solve the problems posed by Cases 3 and 4, and
that advocates for asynchronous actuation. We propose to
use the discrete-time control models given by (17), (18)
and (19), and to approximate the controller to actuator
delay by the related sensor to controller delay.
That is, systems given by (17), (18) and (19) failed to
solve Cases 3 and 4 because those systems require to know
at the beginning of the controller execution the controller
to actuator delay. What we propose is to predict this delay
at each controller execution, according to the related sensor
to controller delay, that is,
ca
=
sc
. Consequently, at each
closed loop execution the sampling-actuation delay will be
given by (24)
k
= 2*
sc
(k) (24)
As we predict the second delay, the prediction will not
be exact. As a first approximation, we model this
inaccuracy assuming that at run time, controller to actuator
delay will occur as we predict, but with an inaccuracy
following a normal distribution with a standard deviation
of 0.1ms according to the sensor to controller delay used
for the prediction. For example, at a given control loop
execution, if the measured sensor to controller delay is
10ms, the controller to actuator delay is predicted to have a
value of 10ms, although at run time, it can take values
from 9.9ms to 10.1ms. In summary, the control models
given by (17), (18) and (19) will be assuming an exact
delay, although varying at each controller execution.
However, at run time, small deviations on the prediction
will occur, deviating thus the actuation.
In order to evaluate this technique, we present the
following simplified set-up: using the inverted pendulum,
we assume that the system given by (17), (18) and (19)
will be expecting a sampling-actuation delay of 20ms
(10ms+10ms). The run time non-predicted small deviations
in the actuation time are simulated using a normal
distribution for controller to actuator delay of 10ms with a
standard deviation of 0.1ms. Therefore, the controller will
assume a known sampling-actuation delay though at run
time, these sampling-actuation delays will suffer small
deviations. Notice that the performance loss is measuring
= =
0 0
) ( ) ( ) ( dt t y t y dt t e V
act nom a
the responses of this ad-hoc technique with the nominal
response obtained by a model given by (11), (12) and (16),
with a constant time delay of 20ms. We show 10
independent simulations (series in Figure 3).
For illustrative purposes, we also evaluate the
performance of the inverted pendulum when:
a) it is controlled by a system given by (11), (12) and (16),
with constant sampling-actuation delay of 25ms (fixed
execution time of 25ms in Figure 3) and
b) b) it is controlled by a system given by (11), (12) and
(16), constant sampling-actuation delays of 20ms (fixed
execution time of 20ms in Figure 3).
Fig. 3. Ad-hoc evaluation technique
We can see again in Figure 3 that the performance of a
control loop over NCS with asynchronous actuation
according to varying time delays (series) is better than
synchronous actuation with a larger time delay (25ms), still
when small deviations occur in the prediction.
As a concluding picture and for final remarks, Fig. 4
shows the system response (inverted pendulum angle)
when:
1. Sampling-actuation delays are not taken into account in
the controller design: degradation (thin dotted line).
2. Control loops with asynchronous actuation assuming
varying and exactly known sampling-actuation delays
know and exact (thick dotted line): unrealistic approach
but optimum response.
3. Control loops with asynchronous actuation predicting
the varying controller-to-actuator delay, although at run
time, small deviation occur (solid line): realistic
approach and sub-optimum response.
Fig. 4. System responses
VII. SUMMARY AND FUTURE WORK
One of the main problems that must be considered in
control loops closed over NCSs is network-induced time
delay. In this paper, we have discussed classical discrete-
time control models with respect to communication delays.
Through simulation results, we have shown that the
performance of control models that allow asynchronous
actuation is better than those that allow synchronous (and
pessimistic, from a timing point of view) actuation.
However, as we pointed out, there is a lack of suitable
control methods to deal with approaches that advocate for
asynchronous actuation. We have presented a ad-hoc
technique for dealing with systems with varying time
delays that allow asynchronous actuation. The performance
evaluation of this technique has shown that although not
being optimal, the achieved performance is better that the
one achieved by standard synchronous models.
Further research will focus on developing more
approaches based on asynchronous actuation.
REFERENCES
[1] K.J. strm and B. Wittenmark. Computer-Controlled
Systems. Third edition. Prentice Hall. 1997
[2] K. Etschberger, Controller Area Network, Basics,
Protocols, Chips and Applications, IXXAT Automat.
GmbH. ISBN 3-00-007376-0, Germany, 2001
[3] Kopetz, H. (1992) Sparse time versus dense time in
distributed real-time systems. In 12th Int. Conf. On
Distributed Computing Systems, pages 460-467,Yokohama,
Japan, June.
[4] F. Lian, J. Moyne, and D. Tilbury. Peformance Evaluation
of Control Networks: Ethernet, ControlNet, and DeviceNet,
IEEE Control Systems Magazine, Feb. 2001, pp. 66-83.
[5] F. Lian, J. Moyne, and D. Tillbury, Networked Design
Consideration for Distributed Control Systems, IEEE
Transactions on Control Systems Technology, Vol 10, No. 2,
March 2002, pp. 297-307.
[6] P. Mart, J. Fuertes, and G. Fohler. An Integrated
Approach to Real-time Distributed Control Systems Over
Fieldbuses, in Proc 8th IEEE Int.Conf. Emerging
Technologies and Factory Automation (ETFA2001). France.
October 2001.
[7] J. Nilsson , Real-time control systems with delays, Ph.D.
dissertation, Dept. automatic Control, Lund Institute of
Technology, Lund, Sweden, January 1998.
[8] V. Sempere, J. Silvestre, J. Mataix, J.M. Fuertes Profibus.
Un Bus de Campo Industrial, CEA-IFAC. ISBN 84-
931327-0-5, Spain, 2002.
[9] E. Tovar. Supporting Real-Time Communications with
Standard Factory-Floor Networks. Ph. D. Dissertation,
Porto University, 1999.
[10] B. Wittenmark, J. Nilsson and M. Trngren, Timing
Problems in Real-Time Control Systems, in Proc. Of the
American Control Conference. US. 1995