TuningGoal.Variance class

Package: TuningGoal

Noise amplification constraint for control system tuning

Description

Use the `TuningGoal.Variance` object to specify a tuning requirement that limits the noise amplification from specified inputs to outputs. The noise amplification is defined as either:

• The square root of the output variance, for a unit-variance white-noise input

• The root-mean-square of the output, for a unit-variance white-noise input

• The H2 norm of the transfer function from the specified inputs to outputs, which equals the total energy of the impulse response

These definitions are different interpretations of the same quantity. `TuningGoal.Variance` imposes the same limit on these quantities.

You can use the `TuningGoal.Variance` requirement for control system tuning with tuning commands, such as `systune` or `looptune`. Specifying this requirement allows you to tune the system response to white-noise inputs. For stochastic inputs with a nonuniform spectrum (colored noise), use `TuningGoal.WeightedVariance` instead.

After you create a requirement object, you can further configure the tuning requirement by setting Properties of the object.

Construction

`Req = TuningGoal.Variance(inputname,outputname,maxamp)` creates a tuning requirement. This tuning requirement limits the noise amplification of the transfer function from `inputname` to `outputname` to the scalar value `maxamp`.

When you tune a control system in discrete time, this requirement assumes that the physical plant and noise process are continuous. To ensure that continuous-time and discrete-time tuning give consistent results, `maxamp` is interpreted as a constraint on the continuous-time H2 norm. If the plant and noise processes are truly discrete and you want to constrain the discrete-time H2 norm instead, multiply `maxamp` by $\sqrt{{T}_{s}}$. Ts is the sample time of the model you are tuning.

Input Arguments

 `inputname` Input signals for the requirement, specified as a string or as a cell array of strings, for multiple-input requirements. If you are using the requirement to tune a Simulink® model of a control system, then `inputname` can include: Any model input.Any linear analysis point marked in the model.Any linear analysis point in an `slTuner` interface associated with the Simulink model. Use `addPoint` to add analysis points to the `slTuner` interface. Use `getPoints` to get the list of analysis points available in an `slTuner` interface to your model. If you are using the requirement to tune a generalized state-space (`genss`) model of a control system, then `inputname` can include: Any input of the `genss` model Any `AnalysisPoint` location in the control system model For example, if you are tuning a control system model, `T`, then `inputname` can be a string contained in `T.InputName`. Also, if `T` contains an `AnalysisPoint` block with a location named `AP_u`, then `inputname` can include `'AP_u'`. Use `getPoints` to get a list of analysis points available in a `genss` model. If `inputname` is an `AnalysisPoint` location of a generalized model, the input signal for the requirement is the implied input associated with the `AnalysisPoint` block: For more information about analysis points in control system models, see Marking Signals of Interest for Control System Analysis and Design. `outputname` Output signals for the requirement, specified as a string or as a cell array of strings, for multiple-output requirements. If you are using the requirement to tune a Simulink model of a control system, then `outputname` can include: Any model output.Any linear analysis point marked in the model.Any linear analysis point in an `slTuner` interface associated with the Simulink model. Use `addPoint` to add analysis points to the `slTuner` interface. Use `getPoints` to get the list of analysis points available in an `slTuner` interface to your model. If you are using the requirement to tune a generalized state-space (`genss`) model of a control system, then `outputname` can include: Any output of the `genss` model Any `AnalysisPoint` location in the control system model For example, if you are tuning a control system model, `T`, then `inputname` can be a string contained in `T.OutputName`. Also, if `T` contains an `AnalysisPoint` block with a location named `AP_y`, then `inputname` can include `'AP_y'`. Use `getPoints` to get a list of analysis points available in a `genss` model. If `outputname` is an `AnalysisPoint` location of a generalized model, the output signal for the requirement is the implied output associated with the `AnalysisPoint` block: For more information about analysis points in control system models, see Marking Signals of Interest for Control System Analysis and Design. `maxamp` Maximum noise amplification from `inputname` to `outputname`, specified as a positive scalar value. This value specifies the maximum value of the output variance at the signals specified in `outputname`, for unit-variance white noise signal at `inputname`. This value corresponds to the maximum H2 norm from `inputname` to `outputname`. When you tune a control system in discrete time, this requirement assumes that the physical plant and noise process are continuous, and interprets `maxamp` as a bound on the continuous-time H2 norm. This ensures that continuous-time and discrete-time tuning give consistent results. If the plant and noise processes are truly discrete, and you want to bound the discrete-time H2 norm instead, specify the value `maxamp`/$\sqrt{{T}_{s}}$. Ts is the sample time of the model you are tuning.

Properties

 `MaxAmplification` Maximum noise amplification, specified as a positive scalar value. This property specifies the maximum value of the output variance at the signals specified in `Output`, for unit-variance white noise signal at `Input`. This value corresponds to the maximum H2 norm from `Input` to `Output`. The initial value of `MaxAmplification` is set by the `maxamp` input argument when you construct the requirement. `InputScaling` Input signal scaling, specified as a vector of positive real values. Use this property to specify the relative amplitude of each entry in vector-valued input signals when the choice of units results in a mix of small and large signals. This information is used to scale the closed-loop transfer function from `Input` to `Output` when the tuning requirement is evaluated. Suppose T(s) is the closed-loop transfer function from `Input` to `Output`. The requirement is evaluated for the scaled transfer function Do–1T(s)Di. The diagonal matrices Do and Di have the `OutputScaling` and `InputScaling` values on the diagonal, respectively. The default value, `[]` , means no scaling. Default: `[]` `OutputScaling` Output signal scaling, specified as a vector of positive real values. Use this property to specify the relative amplitude of each entry in vector-valued output signals when the choice of units results in a mix of small and large signals. This information is used to scale the closed-loop transfer function from `Input` to `Output` when the tuning requirement is evaluated. Suppose T(s) is the closed-loop transfer function from `Input` to `Output`. The requirement is evaluated for the scaled transfer function Do–1T(s)Di. The diagonal matrices Do and Di have the `OutputScaling` and `InputScaling` values on the diagonal, respectively. The default value, `[]` , means no scaling. Default: `[]` `Input` Input signal names, specified as a cell array of strings. These strings specify the names of the inputs of the transfer function that the tuning requirement constrains. The initial value of the `Input` property is set by the `inputname` input argument when you construct the requirement object. `Output` Output signal names, specified as a cell array of strings. These strings specify the names of the outputs of the transfer function that the tuning requirement constrains. The initial value of the `Output` property is set by the `outputname` input argument when you construct the requirement object. `Models` Models to which the tuning requirement applies, specified as a vector of indices. Use the `Models` property when tuning an array of control system models with `systune`, to enforce a tuning requirement for a subset of models in the array. For example, suppose you want to apply the tuning requirement, `Req`, to the second, third, and fourth models in a model array passed to `systune`. To restrict enforcement of the requirement, use the following command: `Req.Models = 2:4;` When `Models = NaN`, the tuning requirement applies to all models. Default: `NaN` `Openings` Feedback loops to open when evaluating the requirement, specified as a cell array of strings that identify loop-opening locations. The tuning requirement is evaluated against the open-loop configuration created by opening feedback loops at the locations you identify. If you are using the requirement to tune a Simulink model of a control system, then `Openings` can include any linear analysis point marked in the model, or any linear analysis point in an `slTuner` interface associated with the Simulink model. Use `addPoint` to add analysis points and loop openings to the `slTuner` interface. Use `getPoints` to get the list of analysis points available in an `slTuner` interface to your model. If you are using the requirement to tune a generalized state-space (`genss`) model of a control system, then `Openings` can include any `AnalysisPoint` location in the control system model. Use `getPoints` to get the list of analysis points available in the `genss` model. Default: `{}` `Name` Name of the requirement object, specified as a string. For example, if `Req` is a requirement: `Req.Name = 'LoopReq';` Default: `[]`

Tips

When you use this requirement to tune a continuous-time control system, `systune` attempts to enforce zero feedthrough (D = 0) on the transfer that the requirement constrains. Zero feedthrough is imposed because the H2 norm, and therefore the value of the tuning goal (see Algorithms), is infinite for continuous-time systems with nonzero feedthrough.

`systune` enforces zero feedthrough by fixing to zero all tunable parameters that contribute to the feedthrough term. `systune` returns an error when fixing these tunable parameters is insufficient to enforce zero feedthrough. In such cases, you must modify the requirement or the control structure, or manually fix some tunable parameters of your system to values that eliminate the feedthrough term.

When the constrained transfer function has several tunable blocks in series, the software's approach of zeroing all parameters that contribute to the overall feedthrough might be conservative. In that case, it is sufficient to zero the feedthrough term of one of the blocks. If you want to control which block has feedthrough fixed to zero, you can manually fix the feedthrough of the tuned block of your choice.

To fix parameters of tunable blocks to specified values, use the `Value` and `Free` properties of the block parametrization. For example, consider a tuned state-space block:

`C = ltiblock.ss('C',1,2,3);`

To enforce zero feedthrough on this block, set its D matrix value to zero, and fix the parameter.

```C.d.Value = 0; C.d.Free = false;```

For more information on fixing parameter values, see the Control Design Block reference pages, such as `ltiblock.ss`.

Algorithms

When you tune a control system using a `TuningGoal` object to specify a tuning requirement, the software converts the requirement into a normalized scalar value f(x). The vector x is the vector of free (tunable) parameters in the control system. The software then adjusts the parameter values to minimize f(x) or to drive f(x) below 1 if the tuning requirement is a hard constraint.

For the `TuningGoal.Variance` requirement, f(x) is given by:

$f\left(x\right)={‖\frac{1}{\text{MaxAmplification}}T\left(s,x\right)‖}_{2}.$

T(s,x) is the closed-loop transfer function from `Input` to `Output`. ${‖\text{\hspace{0.17em}}\cdot \text{\hspace{0.17em}}‖}_{2}$ denotes the H2 norm (see `norm`).

For tuning discrete-time control systems, f(x) is given by:

$f\left(x\right)={‖\frac{1}{\text{MaxAmplification}\sqrt{{T}_{s}}}T\left(z,x\right)‖}_{2}.$

Ts is the sample time of the discrete-time transfer function T(z,x).

Examples

collapse all

Constrain Noise Amplification Evaluated with a Loop Opening

Create a requirement that constrains the amplification of the variance from the analysis point `AP2` to the output `y` of the following control system, measured with the outer loop open.

Create a model of the system. To do so, specify and connect the numeric plant models `G1` and `G2`, and the tunable controllers `C1` and `C2`. Also specify and connect the `AnalysisPoint` blocks `AP1` and `AP2` that mark points of interest for analysis and tuning.

```G1 = tf(10,[1 10]); G2 = tf([1 2],[1 0.2 10]); C1 = ltiblock.pid('C','pi'); C2 = ltiblock.gain('G',1); AP1 = AnalysisPoint('AP1'); AP2 = AnalysisPoint('AP2'); T = feedback(G1*feedback(G2*C2,AP2)*C1,AP1); ```

Create a tuning requirement that constrains the noise amplification from the implicit input associated with the analysis point, `AP2`, to the output `y`.

```Req = TuningGoal.Variance('AP2','y',0.1); ```

This constraint limits the amplification to a factor of 0.1.

Specify that the transfer function from `AP2` to `y` is evaluated with the outer loop open when tuning to this constraint.

```Req.Openings = {'AP1'}; ```

Use `systune` to tune the free parameters of `T` to meet the tuning requirement specified by `Req`. You can then validate the tuned control system against the requirement using `viewSpec(Req,T,Info)`.