You are here : Control System Design - Index | Book Contents | Chapter 1 | Section 1.5

1. The Excitement of Control Engineering


1.5.7 Architectures and Interfacing

The issue of what to connect to what is a nontrivial one in control-system design. One might feel that the best solution would always be to bring all signals to a central point, so that each control action would be based on complete information (leading to so-called centralized control). However, this is rarely (if ever) the best solution in practice. Indeed, there are very good reasons why one might not wish to bring all signals to a common point. Obvious objections to this include complexity, cost, time constraints in computation, maintainability, and reliability.

Thus, one usually partitions the control problem into manageable subsystems. How one does this is part of the control engineer's domain. Indeed, we will see, in the case studies presented in the text, that these architectural issues can be crucial to the final success, or otherwise, of a control system.

Indeed, one of the principal tools that a control-system designer can use to improve performance is to exercise lateral thinking relative to the architecture of the control problem. As an illustration, we will present a real example later in the text (see Chapter 8) where thickness control performance in a reversing rolling mill is irrevocably constrained by a particular architecture. It is shown that no improvement in actuators, sensors, or algorithms (within this architecture) can remedy the problem. However, by simply changing the architecture so as to include extra actuators (namely the currents into coiler and uncoiler motors) then the difficulty is resolved. (See Chapter 10.) As a simpler illustration, the reader is invited to compare the difference in trying to balance a broom on one's finger with one's eyes open or shut. Again there is an architectural difference here--this time it is a function of available sensors. A full analysis of the reasons behind the observed differences in the difficulty of these types of control problems will be explained in Chapters 8 and 9 of the book.

We thus see that architectural issues are of paramount importance in control design problems. A further architectural issue revolves around the need to divide and conquer complex problems. This leads to a hierarchical view of control as illustrated in Table 1.1.


 
Table 1.1: Typical control hierarchy
Level
Description
Goal
Time frame
Typical design tool
4 Plant-wide optimization Meeting customer orders and scheduling supply of materials Every day (say) Static optimization
3 Steady-state optimization at unit operational level Efficient operation of a single unit (e.g., distillation column) Every hour (say) Static optimization
2 Dynamic control at unit operation level Achieving set-points specified at level 3 and achieving rapid recovery from disturbances Every minute (say) Multivariable control (e.g., Model Predictive Control)
1 Dynamic control at single-actuator level Achieving liquid flow rates as specified at level 2 by manipulation of available actuators (e.g., valves) Every second (say) Single variable control (e.g., PID)


Having decided what connections need to be made, there is the issue of interfacing the various subcomponents. This is frequently a nontrivial job, because it is often true that special interfaces are needed between different equipment. Fortunately vendors of control equipment are aware of this difficulty and increasing attention is being paid to standardization of interfaces.