Varying State Space — Control Systems/Linear Parameter Varying

Varying State Space

Control Systems / Linear Parameter Varying

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

dx/dt = A(t)·x + B(t)·u
y = C(t)·x + D(t)·u

A, B, C and D are read afresh at every step, 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 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].
• dx – the state derivative dx/dt, [n,1] – the same quantity the solver integrates, published so a schedule can see it.

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. It does not cross to Simulink (that block has no rate parameter at all), but it is the step the exported core integrates with – see Code export.

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.

The exported core integrates with forward Euler, x ← x + T_s·(A·x + B·u), at the block's sampling period. This is not a shortcut chosen for simplicity: a system whose A/B/C/D are signals cannot be discretized ahead of time the way the fixed-coefficient blocks are, because the matrices are not known until the step runs. An exact per-step discretization would need a matrix exponential inside the core, which is not something the HDL or PLC targets can carry. The consequence is worth stating plainly: the exported core is first-order accurate in T_s where the in-app simulation runs Runge-Kutta, so the two agree to O(T_s) rather than exactly. Choose a period short against the fastest mode you intend to schedule.

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/Varying State Space, with "Initial State Vector" going to InitialCondition as a pass-through value.

The rate does not cross at all. Unlike its Discrete sibling, which carries a Ts parameter, this block defines no rate parameter of any name – it is continuous and takes its step from the surrounding Simulink solver. "Sampling Time (s)" therefore stays on the ICore side. Emitting either SampleTime or Ts would be a hard set_param 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

• Continuous and stateful: the state is the [n,1] vector x, integrated by the solver.
• 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 State Space, which carries a real one.
• dx is the real derivative, computed from the current state and the current coefficients – the same quantity the solver integrates, not a separately estimated one, so it cannot disagree with the state it produces.