None W04B_TransferFunctions_BlockDiagrams

Table of Contents

Challenge

In this notebook, your challenge is to be able to model the behavior of a feedback control system that regulates turbine speed on your friend's dam.

In your last challenge there was an idea that controlling the speed of the turbine on your friend's dam might be best accomplished using feedback. We introduced a diagram of what this might look like before we realized that studying this sort of idea would require linearizing our model before proceeding. Because we linearized this model, I've updated the controller diagram introduced in the last assignment to reflect the fact that with our linearized model we would be requesting a CHANGE in $\Omega$, rather than a total value, in order to use our linearized model for design.

image-2.png

We could potentially calculate the exact correct valve position to achieve the perfect turbine speed $\Delta \Omega$ using our model's steady-state gain, which we found in the last assignment. However that our model is, by definition, only an approximation of reality and in this case we know that approximation is particularly limited since the dam system is not linear from valve position to turbine speed!

This is where feedback is useful. Rather than relying on a "perfect model", a feedback controller adjusts constantly based on the error between a desired output and an actual output.

Let's assume that you were able to derive a linearized differential equation relating the dam's valve position $\Delta u_v$ to its turbine speed $\Delta \Omega$. Maybe this model looked something like this:

$$ a_1 \Delta \dot{\Omega} + a_0 \Delta \Omega = b_0 \Delta u_v$$

where $a_1,a_0,b_0$ are constants derived from your physical parameters, the NOP, and your linearization process.

If we look at the diagram above, the junction symbol on the left graphically represents the calculation of the error $e = \Delta \Omega_d - \Delta \Omega$. However, it may be hard to imagine what the "control law" should look like that would relate a value of the error to a particular valve position. What "policy" should the controller use to "decide" what valve opening $u_v$ is appropriate at any moment?

Well, if $\Delta \Omega = \Delta \Omega_d$, the error $e$ between what we want and what we have is small, and we don't need to open or close the valve.

If $\Delta \Omega << \Delta \Omega_d$, error will be a large positive number, and perhaps we'd like to open the valve a lot to speed up the turbine.

If $\Delta \Omega >> \Delta \Omega_d$, error will be a large negative number, and perhaps we'd like to close the valve a lot to slow the turbine down.

The simplest "rule" we could use to automatically regulate the valve's position to control the turbine is to use what's called proportional feedback control, where:

$$u_v = k_p e = k_p (\Delta \Omega_d - \Delta \Omega)$$

with $k_p$ being a constant that we select.

So how well might this work? How could we use our current set of tools to make a determination?

You may imagine that perhaps we could just substitute this relationship into our differential equation, and see what sorts of effects it might have on the differential equation's characteristics. You'd be right! Let's try it. Our linearized model is

$$ a_1 \Delta \dot{\Omega} + a_0 \Delta \Omega = b_0 \Delta u_v$$

Where $u_v = k_p e = k_p (\Delta \Omega_d - \Delta \Omega)$ according to the "control law." Applying this control law, our model would become:

$$ a_1 \Delta \dot{\Omega} + a_0 \Delta \Omega = b_0 k_p (\Delta \Omega_d - \Delta \Omega)$$

Now, the differential equation has a new input of $\Delta \Omega_d$, rather than its original input of $u_v$.

What else is different?

We could look at the system's characteristics and how they changed when the controller was added. We could look at the "new" differential equation's eigenvalue... its time constant... its settling time.. its steady state gain. We could see how changing the control law's constant $k_p$ affects these parameters as well. So that's it, right? We can use this method to design any controller in ME480?

Well maybe.

But what if we also wanted to add to the diagram above.

What if we wanted to filter the measurement of $\Delta \Omega$ before it reaches the controller, or we need to amplify or attenuate a reading from a sensor?

What if we needed a more complex control law?

What if we wanted to model noise on that sensor and see what effects it might have on the system's performance?

What if we wanted to model effects of "load torque" from the electrical system on how well the controller works?

What if we wanted to include the dynamics of the reservoir in our dam model, increasing the complexity of its differential equation?

We could visually represent some of these things using a picture like the one below:

image.png

Before when we had a simplistic control law, a simplistic model, and only one place where "extra stuff" entered the system (when we calculated error), this allowed us to simply substitute a rule into our original equation. Now, however, there are multiple inputs and multiple differential equations. Using the standard linear, constant-coefficient differential equations tools to understand the picture above is inefficient, and possibly insufficient.

The diagram above, which is called a block diagram, has its own set of rules and tools that can help make complicated analyses of complex, interconnected subsystems (like a controller, a filter, and a model of our original system) not only possible, but also relatively easy.

In the sections below, we will discuss these rules and tools. But first, we will introduce the transfer function, which is how each "block" or subsystem in a block diagram is usually represented. Why? Transfer functions turn differential equations operations into simple algebra! They are tools we use for operational efficiency.

To understand transfer functions, we first need to understand the Laplace Transform.

Model Construction: The Laplace Transform

The Laplace transform is an analytical tool that allows us to turn linear, differential equations into algrebraic equations. This makes them easier to modify, combine, and manipulate. The Laplace transform also allows us to use convenient tables to obtain solutions for differential equations. The laplace transform of a function in the time domain is defined as:

$$F(s) = \mathcal{L}\left|f(t)\right| = \int_0^{\infty} f(t) e^{-st}dt$$

Taking the Laplace transform of a differential equation turns it from an equation with time derivatives into an equation that is a polynomial in "s." For example, assuming zero initial conditions, the term $\frac{d^n y(t)}{dt^n}$ would turn into the term $s^n Y(s)$. In general, including the effects of initial conditions, we can write:

$$\mathcal{L}\left| \frac{d^n y(t)}{dt^n} \right| = s^n Y(s) -s^{n-1} y(0) - s^{n-2}\frac{dy}{dt}(0) - \ldots - s\frac{d^{n-2}y}{dt^{n-2}}(0) - \frac{d^{n-1}y}{dt^{n-1}}(0)$$

Example: Laplace Transform solution of a first order system

Consider the first order system described by the following equation:

$$a_1 \dot{y} + a_0 y = u(t)$$

Taking the Laplace Transform of the entire differential equation yields:

$$a_1 s Y(s) + a_0 Y(s) -y(0) = U(s)$$

At this moment, we can choose to solve the homogeneous portion of the differential equation by setting $U(s)=0$.

$$Y(s) = \frac{y(0)}{a_1 s + a_0}$$

Using the correct entry in the table and scaling/rearranging as necessary would allow us to find $\mathcal{L}^{-1}\left|Y(s)\right|$ and obtain our system's free response to the initial condition $y(0)$.

We could similarly find the system's response to a particular known input $U(s)$ by looking at the system as if the initial condition $y(0) = 0$. If we wanted to model a step input of mangitude $U$, it would be represented as $U(s) = \frac{U}{s}$

To find the system's total response, we could add these two pieces together, thanks to the principle of superposition.

While it is certainly convenient to solve differential equations (especially higher-order differential equations) using the Laplace transform, a table, and tools like the partial fraction decomposition, the true power of the Laplace transform for the controls engineer is that it allows us to represent the system's behavior in its entirety as a polynomial function, rather than as a differential equation.

We can even do this without knowing exactly what the system's input $U(s)$ might be! When we don't know exactly what $U(s)$ might be, or we want to account for any possibility, we can represent a system model as a transfer function, or the ratio of output to input in the Laplace domain.

Model Construction: The Transfer Function Representation of a System

In this course, we'll often need to combine systems to create new ones, or manipulate system models during a controller design process. For this reason, we usually will represent our system as a transfer function, assuming that the system is linear, it has only one scalar input and one scalar output. A transfer function is simply the ratio of a system's output/input.

To obtain the transfer function for a system, assume that its initial conditions are zero. Then, take the Laplace transform of your system's input-output differential equation, and solve for the ratio $\frac{Y(s)}{U(s)}$ where $Y(s)$ represents the system's output, and $U(s)$ represents the system's input.

This procedure will result in a rational function of two polynomials. For a differential equation with $M$ input derivatives and $N$ output derivatives, this looks like:

$$\frac{Y(s)}{U(s)} = \frac{b_m s^M + b_{M-1} s^{M-1} + \cdots + s b_1 + b_0}{a_m s^N + a_{N-1} s^{N-1} + \cdots + s a_1 + a_0}$$

This rational expression contains all of the information we need about our dynamic system model. It allows us to look at the model as an "operator" that can produce output as its function of the input given to the system.

Zeros of the system are the roots of the numerator polynomial, and dictate how the system responds to changes in input.

Poles (eigenvalues) of the system are the roots of the denominator's polynomial, and tell us everything we need to know about the system's intrinsic transient characteristics.

Tools for analyzing transfer function behavior

Finding the Poles of a Transfer Function

The poles of a transfer function are equivalent to the roots of the system's characteristic equation. They are also called its "eigenvalues." You can find the system's characteristic equation by setting its denominator to zero. Eigenvalues with complex components result in oscillatory behavior. All real parts of every eigenvalue must be strictly negative for the system to exhibit BIBO stable behavior.

Finding the zeros of a transfer function

The zeros of a transfer function can be found by setting the numerator of the transfer function equal to zero. Zeros do not affect stability. They merely show us how a system reacts to sudden changes in inputs. Consider the following transfer function:

$$\frac{Y(s)}{U(s)} = \frac{s+b_0}{s+a_0}$$

by the rule above, we can see that this transfer function has one zero at $s = -b_0$. but what does this zero tell us? To understand it, let's simply break the transfer function into two pieces:

$$\frac{Y(s)}{U(s)} = \frac{s}{s+a_0} + \frac{b_0}{s+a_0}$$

So our system can be conceptualized as consisting of two separate systems. By cross-multiplying to study the expression we get:$$Y(s) = \frac{1}{s+a_0} \left(s U(s) + b_0 U(s)\right)$$ Here one "piece" of the system reacts to the input itself $U(s)$, and the other reacts to the derivative of the input, $s U(s)$.

By replacing $s$ with $-b_0$, the larger the magnitude of the zero $\left|-b_0\right|$, the less of a contribution the derivative piece, $sU(s)$ will have on my system's overall response. The smaller the zero's magnitude is, the more important the derivative of the input becomes!!

Initial Value Theorem: Find a model's initial response to an input

Another nice thing about a Laplace Transform representation of a system, especially if that system is in transfer function form, is that there are quick, easy ways to get information about our system's response to an input. The first thing we'd like to know is: at $t=0^+$, what is the value of the system? It started at rest, but it's possible that our input "instantaneously" changed something about the system. This is what the initial value theorem is great for. Let's assume we have a system transfer function $\frac{Y(s)}{U(s)} = T(s)$. Then, the response of our system to a particular input is $Y(s) = U(s)T(s)$.

To find the system's response to the input at time $t=0+$, or just after the input has been applied, we can use the Initial Value Theorem as long as our system is BIBO stable.

If the Laplace transform of a $y(t)$ is $Y(s)$, then the initial value theorem states:

\begin{equation} \lim_{t\rightarrow 0} y(t) = \lim_{s\rightarrow \infty} sY(s) \end{equation}

The Final Value Theorem: Find a model's steady-state, final value

Just like the initial value theorem, the final value theorem allows us to obtain the system's steady-state value given its laplace transform representation. Let's assume we have a system transfer function $\frac{Y(s)}{U(s)} = T(s)$. Then, the response of our system to a particular input is $Y(s) = U(s)T(s)$.

To find the system's response to the input at time $t=\infty$, we can use the Final Value Theorem as long as our system is BIBO stable.

If the Laplace transform of $y(t)$ is $Y(s)$, and if $sY(s)$ is analytic on the imaginary axis and in the right half of the $s$-plane, then

\begin{equation} \lim_{t\rightarrow \infty} y(t) = y_{ss} = \lim_{s\rightarrow 0} sY(s) \end{equation}

The final value theorem is particularly useful for finding a system's steady state gain in response to a particular input (such as a step, although this is not the only input for which a steady state gain may exist). The steady state gain, as before is defined as $K_{ss} = \frac{\Delta y_{ss}}{\Delta u_{ss}}$.

Quickly Simulating a Transfer Function's Response using MATLAB/Octave

MATLAB/Octave have built-in numerical integration functions that make simulating a transfer function's behavior very quick. These can all be explored in more detail by typing "help" and then the function name into a MATLAB prompt or an Octave cell. The functions are:

  • step(), which computes the response of a transfer function system model to a unit (magnitude 1) step input
  • impulse(), which computes the response of a transfer function system model to a unit impulse input
  • ramp(), which computes the response of a transfer function system model to a unit ramp input
  • lsim(), which computes the response of a transfer function system model to an arbitrary input vector.

Many times, using these functions to simulate a system model that you already have in transfer function form is much quicker than writing your own numerical integration solver or solving the system's input-output differential equation analytically (either using the Laplace transform or the method of undetermined coefficients).

Example: Simulating a linear transfer function model's impulse response.

Let's imagine we had the transfer function:

$$\frac{Y(s)}{U(s)} = \frac{s+2}{s^2+2s + 20}$$

And we wanted to know the transfer function's response to a change in input of a 10-unit impulse, assuming that the system began at a value of $y(0) = 1$. We could accomplish this with the following code.

In [1]:
clear all
%set up laplace s
s = tf('s');
%set up TF
T = (s+2)/(s^2+2*s+10);
%simulate TF response to a UNIT impulse
[y,t] = impulse(T);
%scale response by magnitude of input
y = 10*y;
%offset response to account for initial U and initial Y that had the system at a prior steady state value of 1.
y = y+1;

figure()
plot(t,y,'k')
xlabel('Time (s)')
ylabel('System Response (quarks)')

With the basics of transfer functions covered, we can move on to a formal discussion of block diagrams, which are nearly always represented in the laplace domain. Block diagrams show interconnected systems and subsystems represented by their Transfer Functions, and allow us to reduce complex systems-of-systems into a single transfer function representation.

Model Construction: Introduction to the Block Diagram

Block Diagram Basics

As controls engineers, once we have a system model that is our target for a control system design, we're almost always going to add functionality to the system in order to make it do what we want. Because of this, it is tempting to make a picture that describes how our "new" pieces of the system interconnect with the pieces comprising the original, uncontrolled system. The most popular tool for this type of analysis is called the block diagram.

A block diagram shows signals as arrows, operators as shapes.

  1. Signals (inputs, state variables, outputs, and combinations thereof)
  2. Blocks (operators that change one signal into another; usually, these are transfer functions)
  3. Takeoff points (places where a signal goes more than one place)
  4. Summing junctions (places where signals are added or subtracted)

We will go through each of these pieces one by one and discuss what each does.

Signals

A signal in a block diagram can be an input, an output, a state variable, or some combination of state variables in your system. Usually, a block diagram is drawn with the idea that the signals and operators (blocks) shown are in the Laplace Domain.

Blocks

Usually, a block in a block diagram represents a transfer function. If you were to represent the system:

\begin{equation} G(s) = \frac{y(s)}{u(s)} = \frac{1}{s+1} \end{equation}

as a block diagram, it would look like this:

Notice that the signals in the diagram are labeled carefully. We say that the block $G(s) = \frac{1}{s+1}$ operates on the signal $u(s)$ to transform it into $y(s)$.

A block is not always a traditional, proper or strictly proper "transfer function" as seen below.

Blocks in 'cascade'

When two or more blocks are 'in a row' (or 'in series') in a block diagram, we say that the blocks are 'in cascade.' What this means is that the output from the first block is fed into the second.

You could imagine a scenario where a motor takes some voltage input, and drives a pump that produces pressure to move a hydraulic actuator. The key thing here is that by putting blocks (systems or components of systems) in cascade, we assume that they do not 'load' each other. In other words, for our motor/pump/actuator example, we would have to assume that the load on the hydraulic actuator does not affect the dynamics of the motor/pump system. This is sometimes a good assumption, but not always.

A cascade can be replace by one single block that is the product of the two blocks in cascade like this:

Takeoff Points

A takeoff point is simply a point where a signal splits and goes to two different places. This concept is illustrated by the graphic below:

This split could be physical: perhaps it represents a literal connection in an electrical circuit. However, the split could just be for mathematical convenience as well. Many times, as in the first diagram in this reading, a takeoff point is used to represent that the output of a system is fed back to help calculate that system's input. More on this soon.

Summing junctions

At a summing junction, the signal going out of the junction is the sum of the signals coming in.

If it is necessary to subtract one or more signals, a '-' is added next to the corresponding arrowhead.

Blocks in parallel

Sometimes, blocks are set up "in parallel" like you might see electrical elements in parallel in a circuit diagram. This requires a combination of a takeoff point and a summing junction.

To see what's going on here, let's follow the signal from input $u$ to output $y$.

\begin{equation} u\left(\frac{1}{s+a}\right)+u\left(\frac{1}{s+b}\right)=y \end{equation}

When $u$ is factored out, this leaves us with:

\begin{equation} u\left(\frac{1}{s+a}+\frac{1}{s+b}\right)=y \end{equation}

So this system could be replaced with an equivalent block diagram of:

If we find a common denominator between the two parts, this can be reduced even further to:

This process of taking a block diagram and reducing it to a simple diagram with only one block (transfer function) is called block diagram simplification. The formal process for this will be presented in the following sections.

Disciplined Process: Block Diagram Simplification

Why simplify block diagrams?

A control system is usually a device or algorithm that is added to an existing system. Because the goal of any control system is to regulate or improve the performance of the plant so it will likely change the dynamics. That is, the controlled system's eigenvalues will likely change. If we do our job right, they will change "for the better."

By simplifying a block diagram we can obtain a new transfer function representing the controlled system and determine its poles and zeros to evaluate whether our controller actually improved its behavior.

Open loop vs. closed loop controllers

If a controller regulates system behavior without measuring or monitoring the system's output, it is called an open loop controller.

Let's say you want a controlled system to track a 'desired' input $r(s)$ exactly, no matter how hard the controller has to "kick" the system to make that happen. The simplest kind of controller that would do this is an open-loop controller that is simply the inverse of the plant dynamics. Take a look:

We can multiply $G(s)$ and $C(s)$ together and get a simplified block diagram where the "transfer function" connecting $u(s)$ to $y(s)$ is just $1$. That means the output will be identical to the input.

If, on the other hand, a controller regulates system behavior by looking at how far the system is away from some goal at all times, it is called a closed loop controller. This is the type of controller we'll spend nearly all of our time talking about between now and the end of this semester. In general, a closed-loop control system with a controller transfer function $C(s)$ has a block diagram with the following form.

To determine how the controller changed the overall dynamics of our system, we often reduce the block diagram above to something like the following:

What this does for us is gives us a closed loop transfer function that we can use to study the behavior of our system after the controller has been added. By looking at its behavior using the final value theorem, its poles, and its zeros, we can determine whether we have met our performance goals for the system so that $r(s)$, our 'desired input' for the system, and the system output $y(s)$, match each other to our satisfaction. This is almost always the overall goal of block diagram simplification.

Block Diagram Simplification using algebra

To simplify the block diagram in the preceding section, the simplest procedure just involves writing equations to describe the relationship between each of the signals. Giving the signals names here is helpful. Write an equation for each of the summing junctions in the diagram, and write an equation that describes all of the blocks in cascade. For our system, we have:

\begin{aligned} e(s) &= r(s)-y(s)H(s) \\ u(s) &= e(s)C(s) \\ y(s) &= u(s)G(s) \end{aligned}

By substituting these equations into one another, we get the following:

\begin{equation} (r-yH)CG = y \end{equation}

rearranging this equation, we get the following:

\begin{equation} \frac{y(s)}{r(s)} = \frac{CG}{1+CGH} \end{equation}

Block Diagram Simplification with multiple inputs

Sometimes, it is necessary to look at how a second input to a closed-loop, controlled system might affect the output. For instance, on an autonomous car, a side-wind might affect how well the car tracks the center of the road, even under automatic steering. Therefore, you might want to figure out how bad those effects might be when you design your lane-keeping controller for the car. Often, this type of "disturbance," here labeled $d(s)$, is a common source of a second input to a control system's block diagram. For our example, the side-gust might appear as an additive term on the signal $u$, and might represent the lateral acceleration applied to the vehicle as shown below.

To simplify this diagram, we have to decide which transfer function we're looking for in our final, simplified form.

If we want $\frac{y(s)}{r(s)}$, which shows us how the output follows the "desired" behavior for the system, we would assume that $d(s)=0$ and proceed with the algebraic simplification as above.

If we want to see how our wind gust or "disturbance" $d(s)$ affects the output, we want to look at $\frac{y(s)}{d(s)}$, so we set $r(s)=0$ before simplifying.

Because our system has to be linear for us to be using block diagram algebra and transfer functions to describe it, we can say that superposition applies. That means that for any combination of inputs $r(s)$ and $d(s)$, we can compute the total response of the system using the following simplified block diagram:

To find $\frac{y}{d}$, we have to write the equations for each block and summing junction assuming that $r=0$. This gives us:

\begin{aligned} e(s) &= -y(s)H(s) \\ u_c(s) &= e(s)C(s) \\ u_t(s)(s) &= u_c(s)+d(s) \\ y(s) &= u_t(s)G(s) \end{aligned}

Substitution leaves us with:

\begin{equation} (d-yHC)G=y \end{equation}

Moving $y$ to one side and dividing appropriately leaves us with the following closed-loop transfer function from the disturbance $d(s)$ to the output $y(s)$:

\begin{equation} \frac{y(s)}{d(s)} = \frac{G}{1+CGH} \end{equation}

To find find $\frac{y}{r}$ we would do the same steps, just assuming $d = 0$. Under these conditions the block diagram is identical to the first example so

\begin{equation} \frac{y(s)}{r(s)} = \frac{CG}{1+CGH} \end{equation}

note: many example problems of this type are available for you to practice with in Schaum's Outlines of Feedback and Control Systems, and there is also more information in Ch. 6 and 13 of Kulakowski, Gardner, and Shearer's Dynamic Modeling and Control of Engineering Systems.

Exercise: Due at MIDNIGHT on Monday 9/27

Controller Model Construction: Determine the effect of noise on a system's closed-loop response

After explaining your understanding of closed-loop controllers to your friend, they are excited about developing a VERY robost controller and start to ask how you might model a realistically complex control system. Often, a controller uses a combination of feedforward (open loop) and feedback-type (closed loop) control to make the system behave the way we want it to. It's also common to see that a system's output is corrupted by measurement error from faulty or noisy sensors. This "extra" input is often modeled as an input signal that injects errors into 𝑦(𝑠) before the controller 'sees it' as part of the feedback. We will call this error signal 𝑤(𝑠). When the controller measures the output of the system, it's measuring the "wrong" output if the sensor error is nonzero!

To assess how ready you are to start designing your friends dam controller, you challenge yourself to quantify the effects of noise on the complex closed loop system below by using block diagram tools!

Begin by reducing the following block diagram to find the equivalent transfer functions from desired input $r(s)$ to output $y(s)$, and from the measurement error $w(s)$ to the output $y(s)$. Typeset your work and final transfer functions or paste an image of your work in the markdown cell below.

YOUR ANSWER HERE

Use the following fixed assumptions: $$C(s)=10$$ $$G(s)=\frac{1}{s+1}$$ $$H(s)=1$$ $$F(s) = 1$$

Find the total response of the system when $r(s)$ is a unit step, and $w(s)$ is an impulse of magnitude 0.01.

MATLAB's/OCTAVE's impulse() and step() functions could be helpful here. To force step() or impulse() to use a particular time vector (helpful when trying to add repsonses), use the following format

[ystep,tstep] = step(system,tcommon)

or

[yimp,timp] = impulse(system,tcommon)

Here 'system' is your transfer function and 'tcommon' is a common time vector you choose for your response.

To help you check your work, you have the expectation that the end result should look something like a first-order step response with a final value of $1$ at steady state and a time-constant of roughly $0.1$ seconds. Plot the response just due to the input $r(s)$, the response just due to the noise $w(s)$, and the total respose all on the same plot to see the impact of each input on the total response.

In [2]:
clear all
s = tf('s');

% YOUR CODE HERE
error('No Answer Given!')

error: No Answer Given!

Appendix: Block diagram simplification rules and shortcuts

Following signals around and using algebra to simplify block diagrams can get very complex. Here are some shortcuts that will help you "untangle" complex block diagrams on your way to reducing the diagram to a single transfer function.

image.png

In [ ]: