This is machine translation

Translated by Microsoft
Mouseover text to see original. Click the button below to return to the English version of the page.

Note: This page has been translated by MathWorks. Click here to see
To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

Change Requirements with Operating Condition

When tuning a gain-scheduled control system, it is sometimes useful to enforce different design requirements at different points in the design grid. For instance, you might want to:

  • Specify a variable tuning goal that depends explicitly or implicitly on the design point.

  • Enforce a tuning goal at a subset of design points, but ignore it at other design points.

  • Exclude a design point from a particular run of systune, but retain it for analysis or other tuning operations.

  • Eliminate a design point from all stages of design and analysis.

Define Variable Tuning Goal

There are several ways to define a tuning goal that changes across design points.

Create Varying Goals

The varyingGoal command lets you construct tuning goals that depend implicitly or explicitly on the design point.

For example, create a tuning goal that specifies variable gain and phase margins across a grid of design points. Suppose that you use the following 5-by-5 grid of design points to tune your controller.

[alpha,V] = ndgrid(linspace(0,20,5),linspace(700,1300,5));

Suppose further that you have 5-by-5 arrays of target gain margins and target phase margins corresponding to each of the design points, such as the following.

[GM,PM] = ndgrid(linspace(7,20,5),linspace(45,70,5));

To enforce the specified margins at each design point, first create a template for the margins goal. The template is a function that takes gain and phase margin values and returns a TuningGoal.Margins object with those margins.

FH = @(gm,pm) TuningGoal.Margins('u',gm,pm);

Use the template and the margin arrays to create the varying goal.

VG = varyingGoal(FH,GM,PM);

To make it easier to trace which goal applies to which design point, use the SamplingGrid property to attach the design-point information to VG.

VG.SamplingGrid = struct('alpha',alpha,'V',V);

Use VG with systune as you would use any other tuning goal. Use viewGoal to visualize the tuning goal and identify design points that fail to meet the target margins. For varying tuning goals, the viewGoal plot includes sliders that let you examine the goal and system performance for particular design points. See Validate Gain-Scheduled Control Systems.

The template function allows great flexibility in constructing the design goals. For example, you can write a function, goalspec(a,b), that constructs the target overshoot as a nontrivial function of the parameters (a,b), and save the function in a MATLAB® file. Your template function then calls goalspec:

FH = @(a,b) TuningGoal.Overshoot('r',y',goalspec(a,b)); 

For more information about configuring varying goals, see the varyingGoal reference page.

Create Separate Requirement for Each Design Point

Another way to enforce a requirement that varies with design point is to create a separate instance of the requirement for each design point. This approach can be useful when you have a goal that only applies to a few of models in the design array. For example, suppose that you want to enforce a 1/s loop shape on the first five design points only, with a crossover frequency that depends on the scheduling variables. Suppose also that you have created a vector, wc, that contains the target bandwidth for each design point. Then you can construct one TuningGoal.LoopShape requirement for each design point. Associate each TuningGoal.LoopShape requirement with the corresponding design point using the Models property of the requirement.

for ct = 1:length(wc)
   R(ct) = TuningGoal.LoopShape('u',wc(ct));
   R(ct).Model = ct;
end

If wc covers all the design points in your grid, this approach is equivalent to using a varyingGoal object. It is a useful alternative to varyingGoal when you only want to constrain a few design points.

Build Variation into the Model

Instead of creating varying requirements, you can incorporate the varying portion of the requirement into the closed-loop model of the control system. This approach is a form of goal normalization that makes it possible to cover all design points with a single uniform goal.

For example, suppose that you want to limit the gain from d to y to a quantity that depends on the scheduling variables. Suppose that T0 is an array of models of the closed-loop system at each design point. Suppose further that you have created a table, gmax, of the maximum gain values for each design point, σ. Then you can add another output ys = y/gmax to the closed-loop model, as follows.

% Create array of scalar gains 1/gmax
yScaling = reshape(1./gmax,[1 1 size(gmax)]);
yScaling = ss(yScaling,'InputName','y','OutputName','ys');

% Connect these gains in series to y output of T0
T0 = connect(T0,yScaling,T0.InputName,[T0.OutputName ; {'ys'}]);

The maximum gain changes at each design point according to the table gmax. You can then use a single requirement that limits to 1 the gain from d to the scaled output ys.

R = TuningGoal.Gain('d','ys',1);

Such effective normalization of requirements moves the requirement variability from the requirement object, R, to the closed-loop model, T0.

In Simulink®, you can use a similar approach by feeding the relevant model inputs and outputs through a gain block. Then, when you linearize the model, change the gain value of the block with the operating condition. For example, set the gain to a MATLAB variable, and use the Parameters property in slLinearizer to change the variable value with each linearization condition.

Enforce Tuning Goal at Subset of Design Points

You can restrict application of a tuning goal to a subset of models in the design grid using the Models property of the tuning goal. Specify models by their linear index in the model array. For instance, suppose that you have a tuning goal, Req. Configure Req to apply to the first and last models in a 3-by-3 design grid.

Req.Models = [1,9];

When you call systune with Req as a hard or soft goal, systune enforces Req for these models and ignores it for the rest of the grid.

Exclude Design Points from systune Run

You can exclude one or more design points from tuning without removing the corresponding model from the array or reconfiguring your tuning goals. Doing so can be useful, for example, to identify problematic design points when tuning over the entire design grid fails to meet your design requirements. It can also be useful when there are design points that you want to exclude from a particular tuning run, but preserve for performance analysis or further tuning.

The SkipModels option of systuneOptions lets you specify models in the design grid to exclude from tuning. Specify models by their linear index in the model array. For instance, configure systuneOptions to skip the first and last models in a 3-by-3 design grid.

opt = systuneOptions;
opt.SkipModels = [1,9];

When you call systune with opt, the tuning algorithm ignores these models.

As an alternative, you can eliminate design points from the model grid entirely, so that they do not contribute to any stage of tuning or analysis. To do so, use voidModel, which replaces specified models in a model array with NaN. This option is useful when your sampling grid includes points that represent irrelevant or unphysical design points. Using voidModel lets you design over a grid of design points that is almost regular.

See Also

| |

Related Topics