LPV System — Control Systems/Linear Parameter Varying
Control_Systems/Linear_Parameter_Varying/LPV_System · 2 input / 3 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
LPV System
Control Systems / Linear Parameter Varying
Simulates a linear parameter-varying state-space model given on a grid over one to three scheduling parameters: a set of matrices A, B, C and D at every grid point, interpolated at the parameter values arriving on port p, with operating-point offsets:
y = C(p)·(x − x0) + D(p)·(u − u0) + y0
dx = A(p)·(x − x0) + B(p)·(u − u0) + dx0
For a discrete model the next state is dx; for a continuous one the state is integrated by forward Euler at the block's sampling time. Gain-scheduled plants – a model linearized at several operating points – are the usual use.
It is Control System Toolbox's LPV System block, with the model array
given as stacked matrices instead of an ss array.
Ports
- u – the input, a column [m,1].
- p – the scheduling parameters, a column [d,1], one per breakpoint set in use.
- y – the output, a column [p,1].
- x – the state at this sample, [n,1].
- dx – the next state (discrete) or the state derivative (continuous), [n,1].
Parameters
- Breakpoints 1 – the first parameter's strictly increasing grid values, at least two.
- Breakpoints 2, Breakpoints 3 – the second and third parameters', or [] when the grid has fewer parameters.
- Model Type – Discrete or Continuous.
- A – one state matrix per grid point stacked vertically, [n·K, n], K the number of grid points, ordered with the FIRST parameter varying fastest (MATLAB's array order). n is 1 to 8.
- B – the input matrices stacked the same way, [n·K, m].
- C – the output matrices, [p·K, n].
- D – the feedthrough matrices, [p·K, m]. The four tables together may hold at most 4096 numbers.
- Initial State – x at the first sample, [n,1].
- Input Offset u0, Output Offset y0, State Offset x0, Derivative Offset dx0 – the operating point, [m,1], [p,1], [n,1], [n,1]; a scalar is repeated.
- Offsets Are Equilibrium – On (Simulink's default) treats the offsets as an equilibrium and ignores dx0: dx0 is taken as x0 for a discrete model and as 0 for a continuous one. Off uses dx0 as given.
- Interpolation – Flat (the breakpoint at or below), Nearest (ties go up) or Linear (one parameter after the other, the first first).
- Extrapolation – Clip holds the edge matrices; Linear extends the edge segments, and needs Linear interpolation.
- Sampling Time (s) – the block's rate; a continuous model is stepped by forward Euler at it.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. Each prints the same description of the step that the simulation itself runs – the grid search, the interpolation and the state update – so every target does the same arithmetic in the same order. The tables are baked in as constants.
⚠ The three HDL targets run in simulation-only real arithmetic, quantizing only at the port boundaries.
Simulink bridge
None (Support::None). Simulink's block takes its model as
one ss array with a sampling grid, evaluated from a MATLAB expression,
which the bridge cannot build from this block's stacked matrices or read back into
them; the bridge reports this block rather than dropping it silently. Code export
verification still covers it across all ten languages.
Notes
- Discrete only, and stateful: the state persists from sample to sample.
- At most three scheduling parameters. Simulink's state-space bus and offset bus outputs and its delays are not offered.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Linear_Parameter_Varying/LPV_System |
| family | Control_Systems/Linear_Parameter_Varying |
| solver environment class | ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_LPV_System |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Linear_Parameter_Varying/LPV_System/ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_LPV_System.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Linear_Parameter_Varying/LPV_System/ICoreBlock_0_Control_Systems_1_Linear_Parameter_Varying_2_LPV_System.h |
| default size on canvas | 140 × 90 px |
| ports at insert | 2 in, 3 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | u |
| 2 | in | ICoreDouble | p |
| 3 | out | ICoreDouble | y |
| 4 | out | ICoreDouble | x |
| 5 | out | ICoreDouble | dx |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
| Config variable | Default | Simulink parameter |
|---|---|---|
Breakpoints 1 | [0 1 2] | — |
Breakpoints 2 | [] | — |
Breakpoints 3 | [] | — |
Model Type | Discrete%~%Continuous~~Discrete | — |
A | [0.9 0.1; -0.1 0.8; 0.7 0.2; -0.2 0.85; 0.95 0; 0.1 0.6] | — |
B | [1; 0.5; 0.8; 0.3; 1.2; 0.4] | — |
C | [1 0; 0.9 0.2; 1.1 -0.1] | — |
D | [0; 0; 0] | — |
Initial State | [0; 0] | — |
Input Offset u0 | 0 | — |
Output Offset y0 | 0 | — |
State Offset x0 | 0 | — |
Derivative Offset dx0 | 0 | — |
Offsets Are Equilibrium | On%~%Off~~On | — |
Interpolation | Flat%~%Nearest%~%Linear~~Linear | — |
Extrapolation | Clip%~%Linear~~Clip | — |
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::None |
| Simulink path | — |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
Caveat (shown to the user): Simulink's LPV System takes its model as one ss array with a sampling grid, evaluated from a MATLAB expression, which the bridge cannot build from stacked matrices or read back into them. The block is reported rather than dropped when a model crosses
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The checker has a blind spot here — it could not resolve something (a grouped port bullet, a computed config name), which is reported and never counted as a pass. A reader has to settle it:
B0no sample under docs/generated/samples/ — nothing to cross-check (P8.1)
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
LPV System -- a state-space model gridded over scheduling parameters, Control System Toolbox's LPV System A(p), B(p), C(p), D(p) at the points of a grid over one to three scheduling parameters, interpolated at the p arriving on the second port (Flat, Nearest or Linear, one parameter after the other, the first first; Clip or Linear extrapolation), with offsets:
y = C(p) (x - x0) + D(p) (u - u0) + y0 dx = A(p) (x - x0) + B(p) (u - u0) + (equilibrium ? (discrete ? x0 : 0) : dx0)
The arithmetic is ICoreGriddedStateSpaceSupport's, shared with LTV System.
⚠ MEASURED AGAINST R2026a's LPV System over 1-D and 2-D grids and all four interpolation / extrapolation pairs Simulink allows: at most 1.8e-15 in 1-D and 4.4e-16 with the 2-D grid reduced over the first parameter first (the other order reads 8.9e-16 and loses half the bit-identical rows); the emitted Python is bit-identical to the live run.
Sample results#
No sample run is committed for this block. Samples come from the headless harness (DOCS_PLAN.md P8.1) into docs/generated/samples/; until one exists this block's behaviour is witnessed by the parity and export-verification suites, not by a plot here.