Linearizing Simulink Models

From the last video, we have a good understanding of the underlying concept of linearization. At the most basic level, we’re looking at the first order partial derivatives of a function at a steady state operating point and making the assumption that that slope is a good approximation of the nonlinear function as long as we stay close to the operating point. In the water tank example, we solved the partial derivatives by hand, and then used them to build a linear model. But doing this is impractical for arbitrary systems, because analytical derivation can be impossible to accomplish or, at the very least, a time-consuming activity. In those cases, we can turn to modeling and linearization tools within MATLAB and Simulink. However, if we just blindly start linearizing models within Simulink with a general understanding of linearization we’re going to hit a few snags—snags that can be avoided if we have a more practical understanding of how linearization is accomplished. And that’s what we’ll cover in this video. I’m Brian, and welcome to a MATLAB Tech Talk.

To begin, let’s revisit the linearization of the water tank example. The operating point was Hbar = 4. This resulted in a steady state voltage of 2a/b and the linear approximation of Hdot as this function of H and V. Now, let’s open the water tank example in Simulink and see if we can generate the same linear model. With the default a, b, and A values, we’re expecting the steady state voltage to be 0.8V and the linear model to be Hdot = -0.025 H + 0.25 V.

We’ll do this in two parts: First we’ll trim the system at the operating point H bar = 4, and second, we’ll linearize at that steady state condition.

To trim the system, we needed to find the input voltage that would hold the water height exactly at 4 meters, or 4 feet, or 4 parsecs, or whatever units they are.

We’re going to trim using the trimming function within Simulink Control Design. Here, we pick the states and inputs that we want to fix to a specific value and then let the software determine the values of the free states and free inputs that make it steady state. I’ll set the desired height to 4 and let the software calculate the necessary input voltage. And we find that it is, in fact, 0.8 V. So that’s good.

The benefit of the trimming tool is that it works well with complex systems with multiple states and inputs. To see this in action, check out the aircraft trimming example that I’ve linked to in the description below.

Okay, now that we have a trimmed system, we can linearize it around the operating point that we just created and get a linear state space representation of our model. The A matrix is -0.025 and the B matrix is 0.25. Since the output of our model is also the state variable, the C matrix is 1, and since there is no feedforward in this system, the D matrix is 0. This is the exact same result as our hand calculation.

Perfect. So the software does seem to be trimming and linearizing the model in the same way that we did by hand.

Well, Simulink didn’t approach linearization in exactly the same way, and I want to explain why in some detail because understanding how your tools work under the hood will go a long way to figuring out the proper way to use them to get the best result.

With the hand method, we looked at the whole end-to-end differential equation and solved a matrix of partial derivatives. However, Simulink isn’t looking at the entire system as a whole. Instead, it linearizes each block separately and combines the resulting individual linear models to get a full linearized model. This is nice because we can take large, hierarchical models in Simulink—models that would be impractical to reduce to a single differential equation—and instead just focus on each individual block. So let’s do that for the water tank model.

The linear blocks are obviously pretty easy to linearize since, well, they’re already linear. And here are the state space representations for each of them. The water tank model only has the one nonlinear block: the square root function.

How does Simulink handle this? Well, let’s think about how we would approach linearizing this by hand. We’d take the derivative of the function and find the slope at the operating condition. And, in a sense, that’s exactly what Simulink is doing for this block. Many of the nonlinear blocks within Simulink are assigned a Jacobian; it’s hidden within the metadata of the block. And in the case of the square root function, the Jacobian is precisely the derivative of the function. So Simulink uses that to determine the linear model for the square root block.

Once all of the blocks are linearized, they are combined into one single state space representation. This approach is the same idea used in automatic differentiation that is sometimes used to find derivatives of software code. Reducing a model like this is also similar to how you’d reduce a transfer function-based block diagram, where there are rules on how to handle serial blocks, parallel, feedback, and so on. But under the hood, Simulink accomplishes this by formulating the systems as linear fractional transformations, which is an interesting side topic but is beyond the scope of this video.

All right, the model Simulink ended up with by linearizing each individual bock and combining them is exactly the same as the model we created by hand. The reason it’s exact is because the one nonlinear block had an analytically derived Jacobian, so there were no errors introduced through approximations of any kind. Which is pretty awesome, I think.

Okay, that’s the ideal case, having a pre-defined Jacobian. But the nice part about looking at blocks individually is that we can see how the ideal case changes when we use other nonlinear blocks in our model. Instead of using the built-in Simulink block for square root, let’s say we wrote our own MATLAB function block that takes the square root of the input. The MATLAB function block doesn’t have a Jacobian assigned to it since what’s inside the block can be any arbitrary code.

So what happens in this case? Simulink approximates the Jacobian by slightly perturbing the block input and any internal state and measuring the output. To visualize this for the square root function operating around 4, imagine sending through 4.01 and 3.99 and then using the results to calculate a slope. This is a numerical approximation of the Jacobian. The key here is making sure the perturbation step is a proper size to estimate the local slope. Too large and you get more of an average in the area, and too small and you might be linearizing around quantization effects or any high-frequency signals that exists in your code.

If [you] don’t want to rely on the numerical approximation of the Jacobian, there is a third way that Simulink can handle nonlinear blocks. You can decide how you want a nonlinear block to linearize, then assign that linearization to the block. You do this by right clicking and selecting linear analysis, and then specify selected block linearization. For example, I could force my square root function to linearize to some arbitrary state space model of my choosing. Now when I linearize the block, Simulink won’t try to estimate the Jacobian numerically; it’ll just use the specified linearization. And you can see that it, in fact, did this even though the model I gave it behaves nothing like a square root function. So you can use this method to enforce exactly the linearization you want in cases where numerical perturbation might not produce the result you’re looking for. We’ll get to an example of that in a bit.

So these are the ways that Simulink approaches Jacobian linearization: analytically, numerically, and assignedly, or assigned at the block level.

The reason I’m bringing up all of these methods to you is because it’s going to be helpful as we move past differentiable models (or models with a defined slope) and we talk about linearizing discontinuous systems. If it’s not differentiable, then finding the slope at that point doesn’t make much sense, right? Well, it depends on the situation.

Let’s look at rotational friction, which exists within a rotating motor. When the motor is not rotating, there is a breakaway torque required to overcome the sticking torque of friction and just get it moving. At low speeds, there is the nonlinear behavior of Stribeck friction, and then as the motor speeds up, the linear nature of viscous friction becomes dominant. And since friction opposes motion, it’s the exact opposite in the negative direction.

Now let’s think about operating the motor around 0 RPM. For example, you want to build a servo that can rotate in both directions at very low speeds. Does it make sense to design your controller using a linear model at this operating point?

Clearly, frictional torque is discontinuous at the operating point, so we need to think about linearization carefully.

Let’s take the best-case scenario, where the breakaway torque is really small compared to the overall operating torque. There is still friction in the motor, but it’s hardly noticeable. In this case, the behavior of the friction could be reasonably approximated as a straight line, or a gain equal to just the viscous friction. However, as we know, this function isn’t differentiable at 0 RPM even if the discontinuity is really small, so we can’t really get a linear model using the Jacobian. If we tried to linearize this block around 0 RPM in Simulink, it would throw an error, stating that this block produces nonfinite state space matrices. To get around that, we could use our knowledge that the discontinuity at the operating point is insignificant compared to the overall dynamics and just assign this block a specified linearization.

If we take the worst-case scenario, where the breakaway torque is huge, could we still linearize this system? Well, we could assign a specific linearization for the block—we can always do that; however, we may reasonably conclude that a linear model won’t adequately capture the dynamics of the motor around 0 RPM so it wouldn’t make sense to create one. In fact, even if a block is differentiable at the operating point, it may be so highly nonlinear that any linear model, again, will fail to capture the relevant dynamics over the operating region. That is, the region of validity for the linear model is smaller than the region of operation.

This is what I meant earlier when I said we could hit some snags in the linearization process if we don’t fully understand the nature of the system we’re linearizing. Just because a system is not differentiable, doesn’t mean you can’t fit a good linear model to it. But on the flip side, a linear model of a differentiable system that is highly nonlinear might exclude some really important dynamics.

The last thing I want to mention quickly is the difference between linearizing through differentiation, which is what we talked about in this video, and linearizing by fitting a linear model to the system. What I mean is that we can also use system identification and frequency response methods to find a linear model without having to solve the Jacobian. The brief description of this is that we inject a known signal into the system, measure the output, and then come up with a linear model that has similar behavior.

I didn’t want you leaving thinking there was only one approach to linearization, but I’m not going to get into these fitting methods in this video. I’ll leave those topics for future videos.

If you don’t want to miss the next Tech Talk video, don’t forget to subscribe to this channel. Also, if you want to check out my channel, Control System Lectures, I cover more control theory topics there as well. Thanks for watching. I’ll see you next time.