Varying Transfer Function — Control Systems/Linear Parameter Varying

Varying Transfer Function

Control Systems / Linear Parameter Varying

A first-order continuous transfer function whose coefficients are signals, not settings:

y = (b0·s + b1) / (s + a1) · u

b0, a1 and b1 are read afresh at every step, so a scheduling signal can retune the filter while it runs. It is realized in the observer canonical form:

dx/dt = −a1·x + (b1 − a1·b0)·u,   y = x + b0·u

That is not an arbitrary choice among equivalent forms. Any realization of the same transfer function agrees while the coefficients are constant, but once they vary the state means a different thing in each and the outputs diverge. This is the form Simulink's own block uses, which is why the two agree exactly rather than approximately.

Ports

• u – the input signal, of any size [p,m].
• b0 – the numerator's s coefficient, a scalar. It is also the block's direct feedthrough: at b0 = 0 the filter is strictly proper.
• a1 – the denominator's constant term, a scalar. The pole is at s = −a1, so a positive a1 is the stable half and the filter's time constant is 1/a1.
• b1 – the numerator's constant term, a scalar.
• Output – y, the same size as u.

The three coefficient ports must each carry a scalar: the block is first order, and a vector there is a mis-wired signal rather than a per-entry coefficient set. It is reported once the model's port sizes have settled. The filter itself runs element-wise – every entry of u gets its own state, driven by the same three coefficients.

Parameters

• Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. It does not cross to Simulink (that block has no rate parameter), but it is the step the exported core integrates with – see Code export.

There is deliberately no initial-condition parameter: the Simulink counterpart has none either, and inventing one would be a semantic the reference does not have. The state starts at zero.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text.

Only the entry count is fixed at export time; b0, a1 and b1 are read from their signals every step, so the core carries no tunable parameter at all – the coefficient ports stay live on the deployed core.

The exported core integrates with forward Euler, x ← x + T_s·(−a1·x + u). A filter whose coefficients are signals cannot be discretized ahead of time the way Transfer Function is, because they are not known until the step runs. The core is therefore first-order accurate in T_s: choose a period short against 1/a1, the filter's own time constant.

Simulink bridge

Import and export, mapped to cstblocks/Linear Parameter Varying/Varying Transfer Function.

The rate does not cross: this block defines no rate parameter of any name – not SampleTime, and not the Ts its Discrete sibling carries – so "Sampling Time (s)" stays on the ICore side. Emitting either would be a hard set_param error that aborts the whole generated script.

Two Simulink parameters are always implied: N = 1, since this block is first order and N is what moves the coefficient ports, and Feedthrough = on, which is what makes b0 a port at all. Neither has a config behind it because no config value here can add or remove a port.

Notes

• Continuous and stateful: one state per entry of u, integrated by the solver.
• No state space, deliberately, as everywhere in this family: linear at every instant, time-varying overall, so model reduction is right to refuse it rather than merge a snapshot of whatever the coefficient ports happened to carry. For a filter that genuinely does not vary, use Transfer Function.
• The pole is at −a1, and nothing here constrains its sign – a schedule that drives a1 negative makes the filter genuinely unstable, which is the block faithfully doing what it was asked.