Recommendations for Creating Accurate Linearized Models in Simulink

Engineers typically create and work with highly complicated and nonlinear models. However, they often need a linear approximation of these models to apply many engineering analysis and design methodologies practiced, for example, by control engineers. Although the basic concepts behind linearization are relatively simple, there are particular modeling situations that, when linearized, can cause some confusion. In this article we will remove some of this confusion by defining

• what it means to linearize a Simulink model
• what types of Simulink models are suitable for linearization
• how to adjust your models to get accurate linearized results

One challenge in the linearization of Simulink models is that Simulink is an extensive simulation language. You can create models ranging from mechanical and aerospace systems to DSP applications. However, because of this capability, not all blocks within a Simulink model will linearize well and in any model the linearization will depend on the modeling methodologies used.
What is Linearization?

Linearization is a well-known and widely practiced analysis technique typically employed when designing control systems. For relatively simple systems, linearization can be performed by simple hand calculations, but for large systems an automated approach is needed. Simulink and the tools found in Simulink Control Design automate this process.
A linearized model is an approximation based on the derivatives of the system. These derivatives are evaluated at the operating point of the model which includes the values of inputs and states within the model. For more information, see the What is Linearization? chapter of the Simulink Control Design online documentation.
The fundamental concept to understand about linearizing Simulink models is that every block within the linearization path must be individually linearized about its operating point, as depicted in Figure 1. The user defines the linearization path by inserting linearization input and output points in the model. The linearization path is the subset of blocks reachable from the input points and affecting the output points. The operating point for the block depends on the operating point for the model and includes the signal levels at the input and any internal states corresponding to the block.

Figure 1.

For each block within the linearization path, we must ask “What is the behavior of the linearization of this block?” Some blocks in Simulink have preprogrammed exact linearizations. A list of these blocks can be found in the Individual Block Linearization Methods section of the Simulink Control Design online documentation. The remaining blocks in a Simulink model are linearized using numerical perturbation.
Numerically perturbing a block can cause difficulty where the signals are not continuous such as when blocks contain discontinuities and non-double data types. Details of the numerical perturbation algorithms are given in the Simulink Control Design online documentation in the sections Linearization of Simulink Models and Perturbation Algorithm.
A linear approximation of a model is always based at a particular operating point of the model. The linearized model gives a valid approximation to the original model only in a small region around this point, which means that the operating point can have a significant effect on the behavior of the linearized model. For example when you are finding a linear approximation for the function y=u2, the approximation will be very different at u=0 or at u=10 (Figure 2).

Figure 2.

It is important to remember that not only the blocks within the linearization path contribute to the operating point of the model. The output of other blocks can also play a role. Unless the operating point is known exactly or the model is simulated to a steady state condition, it is usually computed using the operating point computation tools found in Simulink Control Design. For more information about operating points used in linearized models, see the Operating Points section of the Simulink Control Design online documentation.
Outline of the Article

The remainder of this article consists of examples that highlight modeling situations that can lead to problems when computing linearized models, with recommendations for ways to avoid these situations. The examples focus on the following modeling situations:

• Blocks with discontinuities
• Blocks with non-double data types
• Pulse Width Modulation (PWM) signals
• Transport Delay and Memory blocks
• Event-based models and triggered subsystems

You can download a copy of all models and MATLAB files used in the following examples.
Blocks with Discontinuities

There are several Simulink blocks that contain discontinuities, such as the Sign block, whose behavior is shown in Figure 3.

Figure 3. Click on image to see enlarged view.

The very large derivatives that occur at the point of discontinuity can cause problems with linearization. For example, the Sign block has the following linearization
D=0, u~=0
D=∞, u==0
where D is a state-space matrix, and u is the input signal to the block.
When these blocks are within the linearization path of your model, the resulting linearized model could potentially have very large values. There is no obvious solution to this problem and it is recommended that you remove or replace these blocks. However, when your model operates in a region away from the point of discontinuity, the linearization will be zero. This should not cause any problems, although when the linearizations of several blocks are multiplied together (as in a feedback path) it can cause the linearization of the system to be zero.
When these blocks are outside the linearization path, they can still contribute to the definition of the operating point of the model but will not otherwise affect the linearization. It is safe to use them for reference signals, disturbances, and any other signals and blocks that are not being linearized.
Other examples of blocks with discontinuities include:

• Relational operator blocks
• Relay block
• Logical operator blocks
• Stateflow blocks
• Quantizer block (has an option to treat as a gain when linearizing)
• Saturation block (has an option to treat as a gain when linearizing)
• Deadzone block (has an option to treat as a gain when linearizing)

Non-Double Data Types

Blocks that have non-double data type signals as either inputs or outputs, and which do not have a preprogrammed exact linearization, will automatically linearize to zero as they cannot be numerically perturbed. For example, many logical operator blocks have Boolean outputs and will therefore linearize to zero.
To work around this problem, you can use a Data Type Conversion block, which does have a preprogrammed exact linearization, to convert your signals to doubles before linearizing the model. The following example illustrates this concept. The model, datatype_model.mdl, is configured to linearize the Square block at an operating point where the input is 1 (Figure 4). The resulting linearized model should be 2 but the input to the Square block is Boolean and the linearization is zero.

Figure 4. Click on image to see enlarged view.

However, by inserting a Data Type Conversion block before the linearization input point, the input signal to the Square block is a double, and the linearized model gives the correct response of 2 (Figure 5).

Figure 5. Click on image to see enlarged view.

Pulse Width Modulation

Many industrial applications use Pulse Width Modulation (PWM) signals because of their robustness in the presence of noise. Figure 6 shows two examples of PWM signals. In the first example, a DC voltage of 0.2V is represented by a PWM signal with a 20% duty cycle (a value of 1 for 20% of the cycle, followed by a value of 0 for 80% of the cycle). The average signal value is 0.2V. The second example shows a similar PWM representation of a 0.8V DC signal.

Figure 6. Click on image to see enlarged view.

The model, pwm.mdl, shown in Figure 7, converts a constant signal to a PWM signal.

Figure 7. Click on image to see enlarged view.

When linearizing a model containing PWM signals there are two effects you should take into account:

• The signal level at the operating point will be one of the discrete values within the PWM signal, not the DC signal value. For example, in the model above, the signal level will be either 0 or 1, not 0.8. This change in operating point will affect the linearized model.
• The creation of the PWM signal within the subsystem Voltage to PWM uses a comparator block, the Compare to Zero block (Figure 8). Comparator blocks do not linearize well due to their discontinuities and the non-double outputs.

Figure 8. Click on image to see enlarged view.

A solution to the two problems described above is to consider removing the PWM block before linearizing the model.
Transport Delay and Memory Blocks

The issues relating to the linearization of models with transport delay and memory blocks are primarily related to the operating points of the model. You need to properly configure the initial outputs of these blocks so that the linearization uses the correct output value. This model, delayex.mdl, in Figure 9, illustrates this issue.

Figure 9. Click on image to see enlarged view.

In this model the Memory block is configured in the block dialog to have an initial output of 0 but is driven by a Constant block with an output of 1. This causes the output signal of the block to be 0 in the operating point. However, in the steady-state operating point for this model, the output of the Memory block is 1. To create a linearized model that is based on this more accurate operating point, select the Direct feedthrough of input during linearization option in the block dialog (Figure 10). This will force the output of the Memory block to be the same as the input during the linearization.

Figure 10. Click on image to see enlarged view.

The problem of block output during linearization also occurs for the Backlash block although, in this case, the block does not have a direct feedthrough option. Extra care should be taken when linearizing a model containing Backlash blocks.
Transport Delay blocks can also cause problems when you use the Padé approximation option for linearization within a multi-rate model. In this case, the discretization of the Padé approximation has a frequency response that does not match the frequency response of the original transport delay. This can lead to linearized models which do not behave as expected. A solution to this problem is to discretize the transport delay first, using the Model Discretizer, and then linearize the model using the Padé approximation.
Event-Based Models and Triggered Subsystems

The linearization of triggered subsystems and other event-based models can be particularly difficult because of the system's dependence on previous events. In particular, the execution of a triggered system depends on previous signal events such as zero crossings. Therefore, for linearization, which takes place at a particular moment in time, a trigger event will never happen. Thus, while the event-based dynamics contribute to the definition of the system's operating point, this information is not captured by the list of values of states and inputs that typically describe the operating point for linearization.
Triggered events describe many different systems. One such system is an internal combustion (IC) engine. When an engine piston approaches the top of a compression stroke, a spark is introduced and combustion occurs. The timing of the spark for combustion is dependent on the speed and position of the engine crankshaft. An example of a Simulink model that models this behavior is engine.mdl, which is included as a demonstration model in Simulink.
In engine.mdl, triggered subsystems generate events when the pistons reach both the top and bottom of the compression stroke. The linearization will not be meaningful because of the presence of these triggered subsystems. However, you can get a meaningful linearization while still preserving the simulation behavior by recasting the event-based dynamics. For example, you can use curve fitting to approximate the event-based behavior. This is done in scdspeed.mdl, a demonstration model included in Simulink Control Design and shown in Figure 11.

Figure 11. Click on image to see enlarged view.

The basic functional approximation in scdspeed is inside the subsystem scdspeed/Throttle & Manifold/Intake Manifold where a quadratic polynomial is used to approximate the relationship between the Air Charge the Manifold Pressure and Engine Speed (N) (Figure 12). The approximation has the following form:
Air Charge = p1 * Engine Speed + p2 * Manifold Pressure + p3 * (Manifold Pressure) 2 + p4 * Manifold Pressure * Engine Speed + p5

Figure 12. Click on image to see enlarged view.

Simulation data from the original model is used to compute the unknown parameters p1, p2, p3, p4, and p5 using a least-squares fitting technique. The MATLAB code to perform the least-squares fit is given in the M-file engine_curve_fit.m.
When measured data for internal signals is available, you can use Simulink Parameter Estimation to compute the unknown parameters. This method is outlined in the related Webinar New & Upgraded Simulink Tools for Developing More Accurate Models & Better Tuned Control Systems.
更多...