Block Diagrams as a System Design "Language": Part 1

This chapter will cover (1) methods of describing a system using block diagrams, using a block diagram "language" that I have found to be very clear and detailed, (2) some examples of other block diagramming "dialects" that you'll see in related literature, and, finally, (3) some methods for analyzing control system behavior using block diagrams.

The Language of Blocks
Figure 4.1 below shows a block diagram. It is probably the world's simplest block diagram, but it is complete, nonetheless. The signal u feeds into a system ("Thing" in the diagram), which transforms it into the signal y.

Figure 4.1. A simple block diagram

The behavior of "Thing" is unspecified, so it could denote any signal processing function that accepts one signal and transforms it into another. What is specified in this block diagram is a single input signal, a single output signal, and the dependence of the output signal on the input signal and its past values, and possibly on the initial conditions of the block "Thing" at some specified point in time.

Figure 4.2. An example block diagram

Figure 4.2, above  is an example of a block diagram showing a simple closed-loop control system. The diagram details a controller, and shows a plant with no detail. In the controller, the command, u comes in from the left, and has the feedback subtracted from it to form the error signal e.

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, which responds with the output to the right of the diagram.

It is best to keep in mind that there are no universally agreed-upon rules of block diagram structure. The language of block diagrams is a living one, and as such it evolves over time and has its own dialects.

There does appear to be a consensus when one is representing systems entirely in the Laplace or z domains, but on the whole, block diagramming is an imprecise science.

As such, it is the responsibility of the system engineer to craft a block diagram that communicates the intended aspects of the system, and to 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-ary operator 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 be expressed if the block diagram is to be complete. Finally, it is often a good idea to annotate one's block diagram by labeling blocks, indicating areas of different sampling rates or indicating what hardware implements what functions, and so forth.

Every block has, at minimum, one signal coming out of it. In general, a block will have one or more input signals and one output signal, but blocks can be easily defined with more than one output as well.

Block diagrams can be hierarchical. Indeed, the entire block diagram detailed in Figure 4.2 could easily be the block labeled "Thing" in Figure 4.1. Further-more, the plant block in Figure 4.2 could (and in a practical application, probably would) be expanded into a block diagram of its own on a separate diagram.

Types of Elements
Signals. A signal is represented by a line with an arrowhead at the end to denote the signal direction, as shown in Figure 4.3, below. At your discretion, it can also be named (the signal below is 'u').

A signal can, in general, be either a scalar signal that carries just one quantity, or a vector that contains a number of individual signals. The choice of whether to bundle signals together into a vector is up to you. To avoid confusion, the elements of a vector signal should be closely related and dissimilar signals should be kept separate.

Figure 4.3. A signal.

Unary Operator Blocks. A unary operator block is represented as a rectangle with signals going into and out of it, and with a symbol or some text to indicate its function. Figure 4.4, below is an example of a unary operator block that operates on the input signal with the transfer function H(z) to create the output signal.

Unary operator blocks are almost invariably shown with the signals traveling horizontally, either right to left or left to right. As with signals, a unary operator block can be named by placing a name above or below it.

Figure 4.4. A unary operator block

A unary operator block indicates that the output signal at any given time is entirely a function of the input signal. Unary blocks can be memory less, where the output signal at any given time is a function of the input signal at that moment.

Unary blocks can also have memory, where the output signal at any given time is a function of the history of the input signal, as is the case when the block implements a transfer function.

(Generally this will be the past history of the input signal, but occasionally an author will show a block diagram that ignores causality and shows blocks whose output signal is a function of the entire history both past and future of the input signal. )

M-ary Operator Blocks
An m-ary operator block is represented as a circle, often containing a symbol or graphics to indicate its function. It will have two or more input signals and an output signal. The output signal is always a memory less combination of the input signals. Figure 4.5 below shows a binary summation block, where z = x " y.

Figure 4.5. A binary summation block

Generally this will be the past history of the input signal, but occasionally an author will show a block diagram that ignores causality and shows blocks whose output signal is a function of the entire history both past and future of the input signal.

Hierarchical Blocks
A hierarchical block is simply a single block that denotes some more complex system thatyou show in detail somewher eelse.It simply indicates thar theere is a system inside the block, with as many inputs as are indicated and as many outputs.

A hierarchical block can look much like a unary operator block, and when it does so can function as one in a larger block diagram. Hierarchical blocks can also indicate more general functions: they can have multiple input signals, multiple output signals, and they can be shown with "auxiliary" I/O where there is some input to or output from the block that is depreciated or designated as being fundamentally different from the "main" signals.

Figure 4.6 Examples of hierarchical blocks

Figure 4.6 above shows some hierarchical blocks. The left most one shows how you might reduce a large single input, single output subsystem down to one block to show it in a larger block diagram. The center block shows how you might represent a system with multiple inputs and multiple outputs, while the last block shows a system with an "auxiliary" input, such a mode input or an on/off input.

A Dictionary of Blocks
Table 4.1 below lists a number of blocks along with the function that they denote. It is by no means comprehensive, but gives a notion of the kind of things that blocks can represent.

Table 4.1 Some blocks and their meanings

Sample and Hold
A sample block is denoted by a switch with a descending arrow, as shown in Figure 4.7, below. The period or frequency of the sample should be denoted underneath the arrowhead, or a 'T' inserted to denote a generic sample-and-hold.

The function of a sample block is to sample a signal at an even rate. It is generally used to show continuous-time signals being converted to discrete-time signals for processing in a digital control system.

It can also indicate a conversion from one discrete-time domain to another in systems where more than one sample rate prevails.

Figure 4.7 Sample

A zero-order hold is a device that transforms a discrete-time signal into a continuous-time one. Figure 4.8 below shows a zero-order hold, with the graphic in the block reflecting the "staircase" appearance of a signal that's been sampled and reconstructed.

Figure 4.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 the language to suit your own purposes. However, this places the responsibility for writing a clear diagram on your shoulders.

Indeed, the exact set of blocks presented here are the invention of the 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 is more clear or universal.

The common control system block diagramming language would show a summation block as in the center or right drawings in Figure 4.9, below; the center figure is the older form, but you will see both. I prefer the block on the left, because it shows explicitly (by means of the sigma) that a summation operation is being performed.

Figure 4.9. Alternate summation block

In radio usage, one will often see a frequency mixer block denoted as a circle with an 'x' inside, similar to the center summation block in Figure 4.9, yet a frequency mixer is generally a type of multiplication, which is certainly a different function from addition!

Figure 4.10 below shows an example, with a mixer/multiplication block on the right and an unambiguous multiplication block on the left. (If you happen to be designing radio equipment you may still have occasion to use the mixer block on the left of Figure 4.10, below: mixer operation can be complex, so denoting one as a simple multiply may not be accurate - the traditional form may be less misleading.)

Figure 4.10. Multiplication or mixer block.

Analyzing Systems with Block Diagrams
Block diagrams would be quite useful enough if all they were used for were to communicate system structure.They can, however, also be used to analyze system behavior, under certain sets of conditions.

If you have a system that can be represented entirely in the z domain (or Laplace), and the transfer functions of all the blocks are known, then the overall transfer function of the system can be determined from the transfer functions of the individual blocks and their interconnections.

Note that the above rule is not always altogether clear, because it is common practice to show a block diagram with a mix of  z- or Laplace-domain blocks and nonlinear blocks, or with a mix of Laplace-domain blocks (indicating a continuous-time system) and z-domain blocks. Such systems can have their differential equations extracted, but they cannot be directly analyzed with the methods shown here.

Direct Equation Extraction
The most obvious method of analyzing a block diagram is to extract the relevant equations from it by inspection, then solve them directly. If the block diagram is fully specified, this technique will always deliver a mathematical model of the system. (Maybe not a solvable one, but a model none the less)

As we'll see, this is not always the best way to proceed, but sometimes it is the only way. (It ignores the fact that the plant is continuous time, among other things.)

Figure 4.11, below is a quite simplified block diagram of a heater control system. The plant is modeled as a heating coil that is driven by a controlled voltage whose power output will be proportional to the square of the drive voltage.

The temperature of the plant is modeled as a low-pass filtered version of the ambient temperature plus a temperature difference that's being driven by the heater coil. The controller is a simple PI controller.

Figure 4.11. An example block diagram

Developing the equations for the diagram in Figure 4.11 is tedious but straight forward. First, find the integrator voltage:

Eq. (4.14)

then the heater offset temperature:

Eq. (4.15)

then the plant temperature:

Eq. (4.16)

Since the system of equations given in (4.14) and (4.16) are nonlinear they are not amenable to easy reduction, so in practice one would solve this equation by time-stepping, or by linearizing (4.16) around some operating point and solving the resulting linear difference equation.

Next in Part 2 in this series, Tim Wescott presents some examples and techniques for analyzing control system behavior by manipulating block diagrams.

Used with the permission of the publisher, Newnes/Elsevier, this series of two articles is based on Chapter 4 -  "Block Diagrams" from Tim Wescott's new book "Applied Control Theory For Embedded Systems."