Discrete Varying Observer Form — Control Systems/Linear Parameter Varying

Discrete Varying Observer Form

Control Systems / Linear Parameter Varying

A discrete observer with state feedback, in which every matrix is a signal rather than a setting. Each sample, in this order:

u[k] = −K[k]·x[k]
ε[k] = y[k] − C[k]·x[k] − D[k]·u[k]
x[k+1] = A[k]·x[k] + B[k]·u[k] + L[k]·ε[k]

The block estimates a plant's state from its measured output y and drives it with the feedback it computes, so a scheduling signal can move the plant model, the observer gain and the feedback gain together while it runs.

Ports

• y – the measured plant output, [p,1].
• A – the state matrix, [n,n]. Its size defines n.
• B – the input matrix, [n,m].
• C – the output matrix, [p,n].
• D – the feedthrough matrix, [p,m].
• K – the state-feedback gain, [m,n]. Note the minus sign is in the block: u = −K·x, so a stabilizing K is the one you would compute for that convention, not its negation.
• L – the observer gain, [n,p], multiplying the innovation.
• u – the computed plant input, [m,1].
• x – the current state estimate x[k], [n,1].
• x+ – the next state estimate x[k+1], [n,1].

The seven sizes must agree exactly, and a disagreement names both offending shapes once the model's port sizes have settled. Nothing is scalar-expanded: these are matrices with a meaning, and expanding one silently would hide a mis-wired schedule.

Parameters

• Initial State Vector – the estimate x[0]. A scalar is used for every state, which is how Simulink's own x0 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.

Only the dimensions n, m and p are fixed at export time, so every loop is statically sized while all seven matrices are read from their signals each step. There is consequently no tunable parameter on the exported core: retuning is what the gain ports are for, and they stay live on the deployed core. Only the initial estimate is emitted as a constant.

Every target emits the three lines in the order above – feedback, then innovation, then update – so the exported core cannot disagree with the simulation about which u the innovation saw.

The three HDL targets carry the arithmetic in Q16.16 fixed point and are fully synthesizable. A gain arriving on a port is already quantized to one Q16.16 quantum (1.5×10^-5) before the block sees it, which is worth knowing for an observer gain L: the innovation it multiplies is a difference of two nearby quantities, so it is the term in this block most sensitive to that quantization.

Simulink bridge

Import and export, mapped to cstblocks/Linear Parameter Varying/Discrete Varying Observer Form, with "Initial State Vector" going to x0 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 be a hard set_param error that aborts the entire generated script rather than a warning that degrades.

OutputX and OutputDX are always implied on: both move ports in Simulink, and the ICore block's port list is fixed at 7 in / 3 out.

Notes

• Discrete only, and stateful: the state is the [n,1] estimate x.
• No algebraic loop, despite D multiplying a signal the block itself produces. u depends on the state alone, so the innovation's D·u term is already known by the time it is needed – which is exactly why the three lines have to run in the order given.
• No state space, deliberately, for the same reason as Discrete Varying State Space: linear at every instant, time-varying overall, so model reduction is right to refuse it rather than merge a snapshot of whatever the gain ports happened to carry.