Using block diagrams as a system design "language" " Part 2
Editor's note: In Part 1 of this series, the basic structural elements and grammar of a block diagram methodology was described. In this part, methods for manipulating block diagrams as an aid to analyzing system behavior are outlined.
Manipulating block diagrams
Initially, one usually draws a structural block diagram. This is a diagram that shows how a system is put together. At some point, one will wish to reduce this structural block diagram into a behavioral diagram.
While this can be done by the techniques shown in Part 1, such techniques immediately sever the connection between the block diagram and the behavioral model, and can be very counter-intuitive to use. It is often better to reduce a block diagram using the manipulation rules presented here.
There are four tools that you have on hand to manipulate block diagrams. Given a block diagram that is described fully in the z domain or the Laplace domain, these tools will allow you to fully analyze the block diagram to extract the overall system behavior.
If you observe their limitations, you can also use these tools on a variety of other block diagrams. The four tools that you have are: cascading gain blocks, moving summing junctions, combining summing junctions, and reducing loops.
The block diagram manipulations shown here will always work if the blocks in question contain pure transfer functions. All of the examples below show block manipulations on blocks containing transfer functions in the z domain; however,these manipulations can be carried out on blocks in the Laplace domain as well.
Stating when a block operation cannot be carried out is more difficult. In general, these operations depend on superposition and cannot be performed when the blocks contain nonlinear operation.
In addition, time varying operations like sampling and zero-order holds can sometimes be moved around and sometimes cannot—generally if you can review this section and make the mathematical equations fit, then you can perform the operation with a block diagram.
When a block diagram indicates a feedback loop, you can reduce the loop to a single transfer function block as shown in Figure 4.12. below. If you look at the equations that govern the behavior of this block diagram, you can see that the output signal is a function of the forward gain G and the error signal e:
The error signal, in turn, is a function of the input and output signals and the feedback gain:
By substituting expressions, we get
which reduces to
|Figure 4.12 Reducing a loop|
Using Loop Reduction
A feedback control system has a forward gain
and negative feedback with a gain of
Draw its block diagram, and find the overall transfer function for the system. The block diagram is a simple feedback loop with the specified gains:
|Figure 4.13 Feedback loop|
From the formula for loop reduction, the transfer function for the system is
This reduces down to the block diagram:
When two blocks are cascaded directly, the transfer function of the combination is the product of the two transfer functions, as in Figure 4.14, below. Looking at the equations that govern the behavior of the block diagram you can see that
From this, it is easy to see that
|Figure 4.14 Cascading gain blocks|
Example. A feedback control system has a plant with a gain of
a controller with a gain of
and unity feedback. Draw its block diagram, and find the overall transfer function for the system.
The block diagram is:
From the gain cascade rule the forward gain is
Using the loop reduction rule with H(z) = 1, the transfer function for the system is
This reduces down to the block diagram:
If a loop contains more than one summing junction, it cannot be reduced by simple loop reduction, and cascading gains will not eliminate the extra junction.
In order to reduce such a loop, the summing junctions must be moved
around until there is a loop with just one summing junction. This is
done by propagating a transfer function backward through the junction,
or its inverse forward through the junction, as shown in Figure 4.15 below.
|Figure 4.15. Moving swimming junctions|
Keep in mind that the inverse transfer function 1/G(z) may not be physically realizable - this is not a concern unless you are trying to use your intermediate results in a real system.
Any manipulations you do here are just for the purposes of making the math easy, and if the system starts as a physically realizable one then any contradictions will disappear by the time you get your solution.
In the top case of Figure 14.5, the input/output relationship on the left is
Using the commutative property of multiplication, this translates to
which corresponds to the input/output relationship on the right.
In the bottom case of Figure 4.15 the input/output relationship on the left is
By using the inverse of the transfer function, the right side becomes
which is functionally the same as the left.
When a block diagram contains a pair of signal paths that originate from the same signal and terminate on a summing junction, the set can be reduced to a single block, as shown in Figure 4.16, below. In this case it can be seen that
From this it is easy to get
|Figure 4.16 Removing parallel paths|
Example using Cascading Gains
Feedforward is often used in control systems to increase the system response speed without having to change a "safe" set of tuning parameters for the loop. Figure 4.17 below shows one such system. We can reduce the block diagram in Figure 4.17 down to a single block.
|Figure 4.17. A system with feedforward|
The loop in Figure 4.17 contains two summing junctions, which prevents the use of the loop reduction rule. We can either move the G1 leg back to the left summing junction, cascading G1 with 1/G2, or we can move the feedback leg forward to the right summing junction, putting a G2 block in the feedback path.
I'll do the latter, to avoid the inverse:
Using loop reduction for the right half and the parallel summation rule for the left gives us a transfer function of:
Multiple Input Systems
So far I've presented systems with just one input and one output (often called SISO systems for "Single Input, Single Output"). Real systems aren't restricted to having just one input and one output, and neither are block diagrams.
Even when you're working with a system that you'd like to treat as a SISO system, you'll find that reality may place additional requirements on your analysis.
It is often very useful to model a disturbance to a system in a block diagram. Figure 4.18 below shows a block diagram (ignoring the continuous time nature of the actuator and plant) with the plant split up into an actuator and a mechanism, and a disturbance force added to the force of the actuator on the mechanism.
This is an example of a multiple input, single output (MISO) system.
When dealing with such a system, you are often interested in its
ability to reject disturbances, so you often want to find the transfer
function from the intended input (u
in this case) as well as the disturbance input (ud).
|Figure 4.18. A block diagram showing a disturbance input|
Both of the transfer functions in question can be found almost by
inspection from Figure 4.18.
This is done by appealing to the fact that we're using a linear system
model, which means that we can use superposition. To find the transfer
function from the intended input to the output, we assume that the
disturbance is set to zero and solve the system normally:
Similarly, to find the transfer function from the disturbance input to the output, we set the intended input to zero and solve the resulting system:
Notice that the denominators in (4.37) and (4.38) are the same. This is a general characteristic of feedback control systems: no matter how many inputs or outputs the system has, no matter how the system behavior may vary when you choose different points to inject signals or observe them, the underlying behavior of the system in terms of the poles of the transfer function will remain the same.
The only times that you will see two different characteristic polynomials in one system will either be because you have two disjoint systems that happen to be on the same page, or because the numerator and denominator of the system share some roots.
(This is called pole-zero cancellation. The cancelled poles haven't ceased to exist—they are just hidden, often to the detriment of real system behavior. Systems with pole-zero cancellation should be treated with all due caution.)
There is one other thing to notice about the system: it is often not necessary to derive all of the transfer functions directly. In this case one could have observed that by moving the summing junction for the disturbance back to the input summing junction the disturbance transfer function could be found from Eq. (4.37), earlier:
If you do the math, you'll see that (4.39) and (4.38) are equal. In many cases it is much easier to derive the desired function by this method rather than solving the block diagram twice.
Multiple Output Systems
A dual of the case with multiple input, single output (MISO) systems are systems with single inputs and multiple outputs (SIMO). As with the multiple input case, one often finds the multiple output case when we would rather be doing a simpler analysis.
Take the case of the command-following system in Figure 4.19, below (which is just Figure 4.18 with the extra summing block removed and some extra signal labels).
With such systems, we're often concerned not only with how well the output is going to follow the input, but what size the control signals will be for a given input.
|Figure 4.19 A command-following system|
If we have a known input and we wish to know the drive signal, we only need to find the transfer function from input to drive and apply the input signal. In this case the block diagram can be reduced by inspection:
This transfer function can be used to predict the drive signal to the actuator for the purposes of checking on actuator heating, actuator drive requirements, and to see if any system parameters are being exceeded...
...This chapter has presented a method of describing a system using block diagrams. It showed how these block diagrams may vary within the control systems community and in the larger signal processing community. I presented methods for bringing some formalism to a block diagram description so that it could be used to analyze system behavior, and methods for manipulating block diagrams to discover how a particular system will behave in a larger sense.
To read Part 1 in this series of articles go to "The language of blocks diagrams and how to use them for embedded control system analysis."
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."Tim Wescott of Wescott Design Services is an expert in the application of control system theory to embedded designs and is a contributor to Embedded Systems Design Magazine and to Embedded.com. In addition to "Sigma-delta techniques extend DAC resolution," he is the author of "PID without a PhD," published in Embedded Systems Design and on-line at Embedded.com, the latter which continues to be one of the most frequently accessed articles on the site.
Currently no items