Control systems engineers use block diagrams extensively in systemanalysis and design. Block diagrams provide two major benefits to thecontrols system engineer: they provide a clear and concise way ofdescribing the behavior and structure of the system, and when the blockdiagram “language” is limited appropriately, they provide formalmethods for analyzing system behavior.
This chapter will cover (1) methods of describing a system using block diagrams, using a blockdiagram “language” that I have found to be very clear and detailed,(2) some examples of otherblock diagramming “dialects” that you'll see inrelated literature, and, finally, (3) some methods for analyzing control system behavior usingblock diagrams.
The Language of Blocks
Figure 4.1 below shows a blockdiagram. It is probably the world's simplest block diagram, but it iscomplete, nonetheless. The signalu feeds into a system (“Thing” in thediagram ), which transforms it into the signal y .
|Figure4.1. A simple block diagram|
The behavior of “Thing” is unspecified, so it could denote anysignal processing function that accepts one signal and transforms itinto another. What is specified in this block diagram is a single inputsignal, a single output signal, and the dependence of the output signalon the input signal and its past values, and possibly on the initialconditions of the block “Thing” at some specified point in time.
|Figure4.2. An example block diagram|
Figure 4.2, above isan example of a block diagram showing a simple closed-loop controlsystem . The diagram details a controller, and shows a plantwith no detail. In the controller, the command, u comes in fromtheleft, and has the feedback subtracted from it to form the error signale .
This error signal is applied to the k p gain block and to an integrator through the k i gain block, then the results are added and applied to the plant, whichresponds with the output to the right of the diagram.
It is best to keep in mind that there are no universally agreed-uponrules of block diagram structure. The language of block diagrams is aliving one, and as such it evolves over time and has its own dialects.
There does appear to be a consensus when one is representing systemsentirely in the Laplace or z domains, but on the whole, blockdiagramming is an imprecise science.
As such, it is the responsibility of the system engineer to craft ablock diagram that communicates the intended aspects of the system, andto accompany it with enough text to clarify its less common aspects.
Block diagrams consist of three main types of elements: signals,unary operator blocks, such as the “Thing” block in Figure 4.1, above , and m-aryoperator blocks such as the two summation blocks in Figure 4.2, above.
In addition, there are other functional elements such as sample-and-hold blocks, complex hierarchical blocks, signal sources, and so on,that don't fit in the three main categories, yet still need to beexpressed if the block diagram is to be complete. Finally, it is oftena good idea to annotate one's block diagram by labeling blocks,indicating areas of different sampling rates or indicating whathardware implements what functions, and so forth.
Every block has, at minimum, one signal coming out of it. Ingeneral, a block will have one or more input signals and one outputsignal, but blocks can be easily defined with more than one output aswell.
Block diagrams can be hierarchical. Indeed, the entire block diagramdetailed in Figure 4.2 couldeasily be the block labeled “Thing” in Figure4.1 . Further-more, the plant block in Figure 4.2 could (and in a practical application, probablywould ) be expanded into a block diagram of its own on a separatediagram.
Types of Elements
Signals. Asignal is represented by a line with an arrowhead at the end to denotethe signal direction, as shown in Figure4.3, below . At your discretion, it can also be named (the signalbelow is 'u ').
A signal can, in general, be either a scalar signalthat carries just one quantity, or a vector that contains a number of individual signals. The choice of whether tobundle signals together into a vector is up to you. To avoid confusion,the elements of a vector signal should be closely related anddissimilar signals should be kept separate.
|Figure4.3. A signal.|
Unary OperatorBlocks. A unary operator block is represented as a rectanglewith signals going into and out of it, and with a symbol or some textto indicate its function. Figure 4.4,below is an example of a unaryoperator block that operates on the input signal with the transfer function H(z) to createthe output signal.
Unary operator blocks are almost invariably shown with the signalstraveling horizontally, either right to left or left to right. As withsignals, a unary operator block can be named by placing a name above orbelow it.
|Figure4.4. A unary operator block|
A unary operator block indicates that the output signal at any giventime is entirely a function of the input signal. Unary blocks can bememory less, where the output signal at any given time is a function ofthe input signal at that moment.
Unary blocks can also have memory, where the output signal at anygiven time is a function of the history of the input signal, as is thecase when the block implements a transfer function.
(Generally this will be the pasthistory of the input signal, but occasionally an author will show ablock diagram that ignores causality and shows blocks whose outputsignal is a function of the entire history both past and future of theinput signal. )
M-ary Operator Blocks
An m-ary operator block is represented as a circle, often containing asymbol or graphics to indicate its function. It will have two or moreinput signals and an output signal. The output signal is alwaysa memory less combination of the input signals. Figure 4.5 below shows abinary summation block, where z = x “y .
|Figure4.5. A binary summation block|
Generally this will be the past history of the input signal, butoccasionally an author will show a block diagram that ignores causalityand shows blocks whose output signal is a function of the entirehistory both past and future of the input signal.
A hierarchical block is simply a single block that denotes some morecomplex system thatyou show in detail somewher eelse.It simplyindicates thar theere is a system inside the block, with as many inputsas are indicated and as many outputs.
A hierarchical block can look much like a unary operator block, andwhen it does so can function as one in a larger block diagram.Hierarchical blocks can also indicate more general functions: they canhave multiple input signals, multiple output signals, and they can beshown with “auxiliary” I/O where there is some input to or output fromthe block that is depreciated or designated as being fundamentallydifferent from the “main” signals.
|Figure4.6 Examples of hierarchical blocks|
Figure 4.6 above shows somehierarchical blocks. The left most one shows how you might reduce alarge single input, single output subsystem down to one block toshow it in a larger block diagram. The center block shows how you mightrepresent a system with multiple inputs and multiple outputs, while thelast block shows a system with an “auxiliary” input, such a mode inputor an on/off input.
A Dictionary of Blocks
Table 4.1 below lists a number of blocks along with the function that they denote. Itis by no means comprehensive, but gives a notion of the kind of thingsthat blocks can represent.
|Table4.1 Some blocks and their meanings|
Sample and Hold
A sample block is denoted by a switch with a descending arrow, as shownin Figure 4.7, below . Theperiod or frequency of the sample should be denoted underneath thearrowhead, or a 'T ' inserted todenote a generic sample-and-hold.
The function of a sample block is to sample a signal at an evenrate. It is generally used to show continuous-time signals beingconverted to discrete-time signals for processing in a digital controlsystem.
It can also indicate a conversion from one discrete-time domain toanother in systems where more than one sample rate prevails.
A zero-order hold is a device that transforms a discrete-time signalinto a continuous-time one. Figure4.8 below shows a zero-order hold, with the graphic in the blockreflecting the “staircase” appearance of a signal that's been sampledand reconstructed.
|Figure4.8. Zero-order hold|
Block Diagram Dialects
Because there are no universal formal definitions of the block diagram”language,” you have the freedom to invent your own dialect of thelanguage to suit your own purposes. However, this places theresponsibility for writing a clear diagram on your shoulders.
Indeed, the exact set of blocks presented here are the invention ofthe author; they generally follow what I have seen to be common usage,but I have made changes from common usage where I feel that my way ismore clear or universal.
The common control system block diagramming language would show asummation block as in the center or right drawings in Figure 4.9, below ; the center figureis the older form, but you will see both. I prefer the block on theleft, because it shows explicitly (bymeans of the sigma ) that a summation operation is beingperformed.
|Figure4.9. Alternate summation block|
In radio usage, one will often see a frequency mixer block denotedas a circle with an 'x ' inside,similar to the center summation blockin Figure 4.9, yet a frequencymixer is generally a type of multiplication, which is certainly adifferent function from addition!
Figure 4.10 below shows anexample, with a mixer/multiplication block on the right and anunambiguous multiplication block on the left. (If you happen to bedesigning radio equipment you may still have occasion to use the mixerblock on the left of Figure 4.10, below: mixer operation can becomplex, sodenoting one as a simple multiply may not be accurate – the traditionalform may be less misleading .)
|Figure4.10. Multiplication or mixer block.|
Analyzing Systems with BlockDiagrams
Block diagrams would be quite useful enough if all they were used forwere to communicate system structure.They can, however, also be used toanalyze system behavior, under certain sets of conditions.
If you have a system that can be represented entirely in the z domain (orLaplace) , and the transfer functions of all the blocks areknown, then the overall transfer function of the system can bedetermined from the transfer functions of the individual blocks andtheir interconnections.
Note that the above rule is not always altogether clear, because itis common practice to show a block diagram with a mix of z – orLaplace-domain blocks and nonlinear blocks, or with a mix ofLaplace-domain blocks (indicating a continuous-time system) andz- domain blocks. Such systemscan have their differential equationsextracted, but they cannot be directly analyzed with the methods shownhere.
Direct Equation Extraction
The most obvious method of analyzing a block diagram is to extract therelevant equations from it by inspection, then solve them directly. Ifthe block diagram is fully specified, this technique will always deliver a mathematical model of the system. (Maybe not a solvable one, but a model nonethe less )
As we'll see, this is not always the best way to proceed, butsometimes it is the only way. (Itignores the fact that the plant is continuous time, among other things. )
Figure 4.11, below is aquite simplified block diagram of a heater control system. The plant ismodeled as a heating coil that is driven by a controlled voltage whosepower output will be proportional to the square of the drive voltage.
The temperature of the plant is modeled as a low-pass filteredversion of the ambient temperature plus a temperature difference that'sbeing driven by the heater coil. The controller is a simple PI controlle r .
|Figure4.11. An example block diagram|
Developing the equations for the diagram in Figure 4.11 is tedious butstraight forward. First, find the integrator voltage:
then the heater offset temperature:
then the plant temperature:
Since the system of equations given in (4.14) and (4.16) are nonlinear theyare not amenable to easy reduction, so in practice one would solve thisequation by time-stepping, or by linearizing (4.16) around some operating pointand solving the resulting linear difference equation.
Next in Part2 in this series, TimWescott presents some examples and techniques for analyzing controlsystembehavior by manipulating block diagrams.
Usedwith the permission of the publisher, Newnes/Elsevier, this series oftwo articles is based on Chapter 4 – “Block Diagrams” from TimWescott's new book “AppliedControl Theory For Embedded Systems.”
Tim Wescott of WescottDesign Services isanexpert in the application ofcontrol system theory to embedded designs and is a contributor toEmbedded Systems Design Magazine and to Embedded.com. In addition to “ Sigma-deltatechniques extend DAC resolution,”he is the author of “ PID without aPhD,” published in EmbeddedSystems Design and on-line at Embedded.com, the latter which continuesto be oneof the most frequently accessed articles on the site.