change requirements with operating condition -凯发k8网页登录

create varying goals

the 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 .

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 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.