Controller Blend 1D — Control Systems/Gain Scheduling
Control_Systems/Gain_Scheduling/Controller_Blend_1D · 2 input / 1 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.
1D Controller Blend
Control Systems / Gain Scheduling
The Aerospace Blockset's 1D Controller Blend: u=(1-L).K1.y+L.K2.y: three self-conditioned state-space controllers, each sitting at one breakpoint of a schedule and each carrying its own state, blended by where the scheduling variable v lies between breakpoints. As v crosses a breakpoint the controllers change ROLES rather than breakpoints, so no controller's state jumps.
A controller at breakpoint j: dx/dt = Hj·u + (Bj − HjDj)·y + (Aj − HjCj)·x, its output Cj·x + Dj·y, where u is the blended output fed back to all three and Hj places the poles of Aj − HjCj at Poles.
With v in the interval [bpk, bpk+1) and fraction f, the three roles are: the controller at bpk+1 with weight f; the one at bpk with weight 1 − f; and a standby, weight 0, at bpk+2 when f ≥ 0.5 or bpk−1 when f < 0.5 (clamped to the table). u = f·uabove + (1 − f)·ubelow. v is clamped to the breakpoints at both ends.
When the interval index goes up by one, every controller moves one role on (above becomes below, below becomes standby, standby becomes above); down by one, one role back. The roles start as above, below, standby. The rotation fires on a rising edge of the index change: an index that changes on two consecutive samples rotates once, and the first sample never rotates – exactly as the Simulink block's triggered subsystems behave.
Ports
- y – the controller input, an [m,1] column, m being the column count of the B and D matrices.
- v – the scheduling variable, a scalar.
- u – the blended controller output, a scalar.
Parameters
- A Matrices – the n×n A matrix for every breakpoint, stacked
vertically in breakpoint order: [P·n, n]. From a MATLAB array
A(:,:,k)the config isreshape(permute(A,[1 3 2]),[],size(A,2)). - B Matrices – the n×m B matrices, stacked: [P·n, m].
- C Matrices – the 1×n C rows, stacked: [P, n]. One output only.
- D Matrices – the 1×m D rows, stacked: [P, m].
- Breakpoints – the P scheduling-variable values, strictly increasing, at least two. Default [1 1.5 2], Simulink's.
- Initial State – every controller's x at the start: a scalar or an [n,1] column. Default 0.
- Poles – the n poles of A − H·C, real and distinct. Default [−5 −2], Simulink's.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Hj is computed at the start of a run by Ackermann's formula on the observer
dual. With one output that is the only gain placing the poles, so it is the one Simulink's
place returns; the configuration is refused if a C row and its A leave the state
unobservable, if two poles coincide, or if C has more than one row.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The schedule, the gains H and the matrices A − HC and B − HD are baked in; the role machine and the three states integrate with forward Euler at the block's period. All ten are rendered from the one description of the arithmetic the block's own simulation runs.
The three HDL targets are simulation-only: the fraction divides by a signal
difference, so they compute in real arithmetic and quantize only at the ports.
Simulink bridge
None (Support::None), for the 1D Controller's reason: the four matrix
parameters of aerolibschedule/1D Controller Blend are three-dimensional
arrays, and neither MATLAB's matrix literal syntax nor an ICore matrix config has that
form. The block is reported rather than exported without its matrices; it has no parity
testbench, and code export verification covers it.
Notes
- Discrete by nature here: the roles are a per-sample state, so the block always steps at its own period. The Simulink block is continuous; at the same fixed step under its Euler solver the two agree exactly.
- Stateful: 3n controller states plus the role machine. Direct feedthrough always: the weights are the Prelookup fraction of v at the same instant, so the output moves with v even with every D row zero.
- The standby controller's state still evolves, fed the blended output, so it is ready when the roles rotate it in.
- In the three HDL targets v arrives in Q16.16, so a v within one quantum (1.5×10−5) of a breakpoint can fall in the other interval, and the roles then rotate on a different sample than a double-precision run would. The blended output is continuous across a breakpoint, but the role machine is not, so treat a red HDL cell on this block as a re-run before a diagnosis.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Gain_Scheduling/Controller_Blend_1D |
| family | Control_Systems/Gain_Scheduling |
| solver environment class | ICoreBlock_0_Control_Systems_1_Gain_Scheduling_2_Controller_Blend_1D |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Gain_Scheduling/Controller_Blend_1D/ICoreBlock_0_Control_Systems_1_Gain_Scheduling_2_Controller_Blend_1D.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Gain_Scheduling/Controller_Blend_1D/ICoreBlock_0_Control_Systems_1_Gain_Scheduling_2_Controller_Blend_1D.h |
| default size on canvas | 150 × 90 px |
| ports at insert | 2 in, 1 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 | y |
| 2 | in | ICoreDouble | v |
| 3 | out | ICoreDouble | u |
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 |
|---|---|---|
A Matrices | [0 1; -2 -3; 0 1; -3 -3.5; 0 1; -4 -4] | — |
B Matrices | [0; 1; 0; 1; 0; 1] | — |
C Matrices | [1 0; 1 0; 1 0] | — |
D Matrices | [0; 0; 0] | — |
Breakpoints | [1 1.5 2] | — |
Initial State | 0 | — |
Poles | [-5 -2] | — |
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): aerolibschedule/1D Controller Blend computes exactly what this block does -- measured to 0 under ode1, role machine included -- but its four matrix parameters are THREE-DIMENSIONAL arrays, one slice per breakpoint, and neither MATLAB's matrix literal syntax nor an ICore matrix config has a three-dimensional form. So the schedule cannot cross in either direction; reported rather than exported to a counterpart that would be missing its matrices
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
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).
1D Controller Blend: u = (1-L).K1.y + L.K2.y -- three scheduled self-conditioned controllers Each controller i sits at ONE breakpoint j and carries its own state: dx_i/dt = H_j*u + (B_j - H_j*D_j)*y + (A_j - H_j*C_j)*x_i, u_i = C_j*x_i + D_j*y H_j = place(A_j', C_j', Poles)' and the output blends the two around v: u = (f*u_above + (1-f)*u_below) + 0*u_standby.
MEASURED AGAINST R2026a, by reading every inner block of the mask (the three K subsystems, the "Controller indices" subsystem with its Memory blocks, three triggered index subsystems and six multiport switches) and then simulating a reference built from that reading against the real block under ode1: EXACTLY 0 over 800 samples in each of three runs -- a slow sweep of v across four breakpoints, WHITE NOISE on v (the interval index changing on consecutive samples), and v starting in the middle of the table.
⚠ THE ROLE ROTATION IS A RISING-EDGE TRIGGER, and that is the part a reading of the help page gets wrong. The three index subsystems are triggered by |k - k_prev| with a RISING trigger and "no trigger on first evaluation" -- so a rotation fires only when the index change rises FROM ZERO. An index that changes on two consecutive samples rotates the roles ONCE, and a first interval other than 0 (k_prev starts at 0) swallows the first real change. The white-noise run matches only with both.
Discrete by nature here: the role machine is a per-sample state (the Simulink block keeps it in Memory blocks), so the block steps at its own period with forward Euler -- exactly what the real block computes under ode1 at that period.
NO SIMULINK BRIDGE, for the 1D Controller's reason: four three-dimensional matrix parameters.
Sample results#
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 0.02693 |
ramp | Ramp: slope 1 from t = 0 | 0 … 1.225 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -0.1618 … 0.2369 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -0.08306 … 0.1745 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category dynamic · sample time 0.1 · 60 steps · commit 93133d604 · produced by docsSample --out <folder> --blocks Gain_Scheduled_Lead_Lag Controller_1D Controller_Blend_1D Controller_2D Controller_3D Observer_Form_1D Self_Conditioned_1D Line_Of_Sight_Access Orbit_Propagator_Kepler Attitude_Dynamics Attitude_Profile_Nadir_Pointing Attitude_Profile_Geographic_Pointing Multitaper_PSD Cross_Power_Spectral_Density Transfer_Function_Estimate Envelope_Spectrum Compose_String Scan_String --steps 60 · data docs/generated/samples/Control_Systems__Gain_Scheduling__Controller_Blend_1D.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).