Discrete Varying State Space — Control Systems/Linear Parameter Varying

Discrete Varying State Space

Control Systems / Linear Parameter Varying

A discrete state-space system whose matrices are signals, not settings:

x[k+1] = A[k]·x[k] + B[k]·u[k]
y[k] = C[k]·x[k] + D[k]·u[k]

A, B, C and D are read afresh on every sample, so a scheduling signal can move the system while it runs – the linear parameter-varying (LPV) realization. At any one instant the block is exactly the ordinary Discrete State Space; across instants it is not, which is what the varying matrices buy and what the Notes below say the cost of is.

Ports

• u – the input vector, [m,1].
• A – the state matrix, [n,n]. Its size is what defines n: the state count is taken from this port, not from any parameter.
• B – the input matrix, [n,m].
• C – the output matrix, [p,n].
• D – the feedthrough matrix, [p,m].
• y – the output vector, [p,1], from the current state.
• x – the current state x[k], [n,1].
• x+ – the next state x[k+1], [n,1], the same value this block will use itself on the following sample.

The five sizes must agree with one another exactly – A square, B and D sharing u's width m, C and D sharing y's height p – and a disagreement is reported with the two offending shapes once the model's port sizes have settled. Nothing is scalar-expanded here: these are matrices with a meaning, and a silent expansion would hide a mis-wired schedule.

Parameters

• Initial State Vector – x[0]. A scalar is used for every state, which is how Simulink's own initial condition behaves and the only form that can be written before n is known; an [n,1] vector sets each state separately. Defaults to 0.
• Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.

Code export

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

Nothing about the system is baked into the generated core except its dimensions: n, m and p are fixed at export time, so every loop is statically sized, while A, B, C and D are read from their input signals on every step exactly as they are in simulation. There is consequently no tunable parameter on the exported core – retuning is what the coefficient ports are for, and they remain live on the deployed core. Only the initial state is emitted as a constant, since it is consumed once before the first sample.

The three HDL targets carry the recursion in Q16.16 fixed point and are fully synthesizable. Note that a coefficient arriving on a port is already quantized to one Q16.16 quantum (1.5×10^-5) before the block sees it, so a schedule that relies on finer coefficient resolution than that will not survive an HDL export, however exactly the software targets reproduce it.

Simulink bridge

Import and export, mapped to cstblocks/Linear Parameter Varying/Discrete Varying State Space, with "Initial State Vector" going to InitialCondition as a pass-through value.

The rate crosses under a different name. This Simulink block calls its rate parameter Ts, not SampleTime, so the catalog entry names it explicitly. Emitting the usual name would not degrade gracefully: a set_param for a parameter a block does not define is a hard MATLAB error that aborts the entire generated script.

Four Simulink parameters are always implied rather than offered as a choice, because each of them moves ports and no config value here can add or remove one: Feedthrough = on (the D input), OutputX = on and OutputDX = on (the x and x+ outputs), and InitialConditionSource = internal. The four external-initial-value inputs (InputX0, InputDX0, InputU0, InputY0) stay off for the same reason.

Notes

• Discrete only, and stateful: the state is the [n,1] vector x.
• No state space, deliberately. The block is linear at every instant but time-varying overall, so there is no single A/B/C/D to hand to model reduction or the linear-analysis commands, and they report it as unmergeable. That is the correct answer rather than a limitation: a state space seeded from whatever the coefficient ports happened to carry would be a snapshot, and merging it into a neighbouring plant would produce a model that is wrong the moment the schedule moves. For a system that genuinely does not vary, use Discrete State Space, which carries a real one.
• x+ is not a preview of a re-read. The x+ output is the same value the block stores, computed from the current state and the current coefficients, so feeding it back into a schedule cannot disagree with what the block does next.