Skip to content

Reference Slew-Rate Limit

Control rule — instantiates Reference Tracking Bandwidth Alignment

Caps the rate at which the setpoint may move so the loop always has time to settle between updates.

Version
v1 · 2026-08-24 · History
Mechanism #
7264
Type
Control Rule
Form family
Control, Automation & Runtime
Solution family
Stress Testing & Rehearsal
Problem family
Timing, Transition & Path-Dependence Failure
Problem subfamily
Cadence, Phase, Tempo & Recovery Alignment
Origin domain
Engineering & Design
Also from
Systems Thinking & Cybernetics
Instantiates
Reference Tracking Bandwidth Alignment

A Reference Slew-Rate Limit puts a speed limit on the reference itself. However fast the raw target wants to jump, the rule lets the setpoint the loop actually chases move no faster than a chosen maximum rate — so a step command becomes a ramp and a fast wobble becomes a gentle glide. Its defining idea is rate capping: the limit constrains how quickly the reference may change per unit time, sizing that cap to what the loop can physically follow. It says nothing about how large a change is or whether a small one is worth ignoring; it governs only speed, filling the gap between the reference-setter's impatience and the loop's finite ability to keep up.

Example

A modern fly-by-wire airliner never lets the pilot's stick command reach the control surfaces raw. If a startled pilot slams the sidestick to demand an instant 45-degree roll, a Reference Slew-Rate Limit in the flight-control law caps the commanded roll rate — the reference bank angle is allowed to advance at, say, no more than a set number of degrees per second toward the target. Setup to outcome: the aircraft still rolls to 45 degrees, but along a rate the airframe and the control loop can track smoothly, without the abrupt, oscillatory response an uncapped step would provoke. The pilot's intent is honoured; only the speed at which the reference is delivered to the loop is bounded, so the loop is never handed a change faster than it can follow. The cap is set from the loop's own response bandwidth — fast enough to feel responsive, slow enough that the surfaces and dynamics always keep pace.

How it works

At each update the rule compares the new demanded reference to the current shaped reference and permits the shaped value to move toward it by at most the rate limit times the time step. Large jumps are converted into rate-limited ramps that arrive over several cycles; the loop tracks the ramp, which by construction never outruns it. The single number that matters is the maximum allowed rate, chosen just below the loop's demonstrated ability to follow — fast enough to preserve responsiveness, slow enough that the loop settles continuously rather than chasing a target that has already leapt ahead. It is a continuous, automatic cap applied to every movement, not a decision made per event.

Tuning parameters

  • Maximum slew rate — the cap on reference change per unit time. Higher preserves responsiveness but risks handing the loop more than it can follow; lower guarantees tracking but adds lag on genuine fast moves.
  • Asymmetric limits — separate up-rate and down-rate caps, useful when the loop settles faster in one direction (e.g. gravity-assisted descent versus climb).
  • Rate scheduling — letting the cap vary with operating condition, load, or how far the reference must travel, trading simplicity for fidelity to a nonlinear loop.
  • Saturation handling — what happens to the backlog when the demanded reference keeps outrunning the cap: track the ramp only, or preserve the final target to reach eventually.

When it helps, and when it misleads

Its strength is that it guarantees the loop is never asked to do the impossible: with the reference rate bounded to loop bandwidth, persistent chase-error from over-fast setpoints simply cannot arise. It is the cleanest, most local cure for a loop being handed step changes it was never built to follow.

It misleads when the cap is set wrong or the world genuinely demands speed. Too low a limit is lag: the loop faithfully tracks a reference that arrives too slowly to matter, and in fast, closed-loop systems an over-tight rate limit can itself induce oscillation — the rate-limiting-driven pilot-induced oscillation known in aviation as a Category-II PIO, where the cap adds phase lag that destabilises the very loop it was meant to calm.[n1] The classic misuse is slewing a safety-critical reference so slowly that the system cannot respond to a real emergency. The guarding discipline is to size the cap from a measured loop response, provide a faster path (or bypass) for genuine emergencies, and watch for the phase lag the limit adds under aggressive commanding.

How it implements the components

  • reference_shaping_rule — it shapes the reference by capping its rate of change, the core "smooth/constrain" move of reference shaping.
  • effective_loop_bandwidth_estimate — the cap is set from the loop's response bandwidth, so the rule embeds and operationalises that estimate as a slew number.
  • reference_cadence_profile — it directly addresses the slew-rate dimension of the demanded cadence, converting an over-fast cadence into a trackable one.

It does NOT implement stability_and_safety_guardrail or tracking_error_decomposition — gating out sub-threshold noise and rapid reversals belongs to Hysteresis or Deadband Window, its nearest control-rule twin. The slew-rate limit caps how *fast the reference may move; the deadband decides how small a move to ignore — different dials on different quantities.*

Editorial Notes

Form Classification

Form family: Control, Automation & Runtime

Rationale: Reference Slew-Rate Limit operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it caps the rate at which the setpoint may move so the loop always has time to settle between updates.

Independent corroboration: The frozen evidence defines Reference Slew-Rate Limit as 'Caps the rate at which the setpoint may move so the loop always has time to settle between updates', so its operative form is Control, Automation & Runtime.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution

Primary origin: Engineering & Design

Origin pattern: Single lineage

Present-day reach: Specialized

Rationale: Slew-rate limiting of changing references is an established control-engineering technique.

Related originating lineages:

Review resolution: Both blind reviewers agree that engineering_design is the primary origin. Explicit reconciliation of origin mode disagreement adopts reviewer_a's classification because slew-rate limiting of changing references is an established control-engineering technique. The resulting lineage records alternates=systems_cybernetics, origin_mode=single_lineage, and domain_reach=specialized; these describe formative provenance separately from later applicability.

Review outcome: Reconciled after independent review; high confidence.

Notes

[n1] Category-II pilot-induced oscillation — a class of aircraft PIO in which rate limiting in the flight-control path introduces phase lag that couples with the pilot's own corrections to produce sustained oscillation. It is the canonical warning that a rate limit is not free: set too aggressively, the very device meant to smooth a reference can destabilise the loop.