Actuator Saturation Alarm¶
Monitor — instantiates Reference Tracking Bandwidth Alignment
Fires when tracking error stops responding to effort because the actuator or capacity has hit its ceiling — reattributing the lag from willingness to bandwidth.
The Actuator Saturation Alarm watches one thing: whether the loop's actuator is already commanded to its physical limit while error still persists. When it is, more effort cannot help — the correction the loop wants to make is larger than the correction it is physically able to deliver. The alarm exists to catch exactly that condition and say so out loud, converting a silent, misread lag into an explicit signal that the binding constraint is capacity, not commitment. Its single defining idea is reattribution: a persistent error is normally read as someone underperforming, but once the actuator is pinned at 100%, the alarm reclassifies the residual as a bandwidth fact the surrounding system must fix structurally, not exhort away.
Example¶
A municipal water utility asks a pump station to hold 60 psi across a residential district. Most of the day it does. But during the 7 a.m. shower-and-coffee spike, pressure sags to 48 psi and stays there for the better part of an hour, and the reflex in the ops meeting is to ask why the shift operator "isn't holding setpoint." The Actuator Saturation Alarm is wired to the variable-frequency drive on the lead pump. It only fires under a specific coincidence: the drive commanded to full output and pressure error still open and both persisting past a short dwell window. On the morning in question it latches at 7:06 and clears at 7:41 — a 35-minute "capacity-bound" stretch. The outcome is that the review stops interrogating the operator and starts interrogating the installed capacity: the pump curve simply cannot serve peak demand at target pressure. The fix moves to adding a jockey pump and staggering a large irrigation customer off the morning peak — structural moves the alarm made legible.
How it works¶
The alarm compares the commanded actuation to the actuator's known limit, not the measured output to the setpoint. Saturation alone is not enough to fire — a healthy loop saturates briefly on every large transient. The alarm fires only on the conjunction of three conditions: command at (or within a margin of) the ceiling, error still non-zero in the same direction, and both sustained past a debounce interval that filters normal transients. On firing, it tags the residual error to the actuation term of the loop's error breakdown and, optionally, freezes integrator accumulation so the controller does not wind up demanding a correction it can never deliver.
Tuning parameters¶
- Saturation margin — how close to the hard limit counts as "saturated." Tighter catches true ceilings only; looser warns earlier but flags healthy hard-pushing loops.
- Dwell / debounce window — how long the condition must hold before latching. Longer suppresses transient nuisance alarms but delays the real signal.
- Error-coexistence gate — whether saturation must coincide with open error to fire. Requiring it prevents alarms during benign at-limit operation with zero error.
- Windup-freeze coupling — whether firing also halts integral accumulation. On protects against overshoot when the limit releases; off keeps the controller "ready" but risks a lurch.
- Latch vs. auto-clear — whether the alarm holds until acknowledged or clears when the condition lifts. Latching preserves the audit trail; auto-clear reduces clutter.
When it helps, and when it misleads¶
Its strength is diagnostic honesty: it is the cheapest way to break the "track harder" misdiagnosis, and pairing it with a windup freeze also protects the loop from the classic post-saturation lurch known as integral windup.[n1] A saturation-bound loop that keeps accumulating command will overshoot violently the instant capacity frees up; the alarm is the natural place to guard against that.
It misleads in two ways. A loop that saturates every single morning produces an alarm that becomes wallpaper — the alarm-fatigue failure, where a chronically-true signal stops being read at all. And a genuinely fixable inefficiency (a throttled valve, a mis-sized gain) can masquerade as saturation, letting a team excuse a problem they could actually solve. The guarding discipline is to route every sustained or recurring firing into a capacity review rather than an acknowledgement queue: the alarm names the bottleneck, it does not license leaving it there.
How it implements the components¶
tracking_error_decomposition— it isolates and attributes one specific term of the error, the actuator-saturation component, separating it from effort, delay, and noise.effective_loop_bandwidth_estimate— a firing is direct evidence that actuation is the loop's binding segment, sharpening the whole-loop bandwidth picture at the point it actually pinches.stability_and_safety_guardrail— the windup freeze and overload flag keep a saturated loop from building an unsafe pent-up correction.
It does NOT implement reference_cadence_profile or controlled_variable_and_reference_path — the comparative reference-speed-versus-bandwidth display belongs to Trackable Envelope Chart, its nearest observability twin; this alarm emits one binary signal about a single term, the actuation ceiling, rather than a dashboard of the whole mismatch.
Related¶
- Instantiates: Reference Tracking Bandwidth Alignment — the alarm supplies the "actuation is the bottleneck" evidence the archetype's diagnosis depends on.
- Sibling mechanisms: Trackable Envelope Chart · Priority-Band Triage Rule · Untrackable Demand Exception Record · Reference Slew-Rate Limit · Feedforward Prepositioning Plan
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: The mechanism fires when tracking error stops responding to effort because the actuator or capacity has hit its ceiling — reattributing the lag from willingness to bandwidth, so its operative form is repeated observation and operational signaling.
Independent corroboration: The frozen evidence defines Actuator Saturation Alarm as 'Fires when tracking error stops responding to effort because the actuator or capacity has hit its ceiling — reattributing the lag from willingness to bandwidth', so its operative form is Monitoring, Sensing & Alerting.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Detecting a commanded actuator at its physical limit while control error persists is a standard control and process-engineering diagnostic, closely associated with saturation and anti-windup practice.
Related originating lineages:
- Robotics & Automation — Joint limits, motor saturation, and industrial drive alarms provide recurring automated-system implementations.
- Systems Thinking & Cybernetics — Persistent error despite maximum control effort expresses the cybernetic distinction between controller intent and available regulatory variety.
Review resolution: Persistent tracking error while a physical actuator is at its limit is an installed control-engineering diagnostic, including anti-windup protection. Cybernetics explains the feedback structure and robotics is a major implementation lineage, but engineering supplies the concrete alarm practice.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Integral windup — in a controller with integral action, the accumulator keeps summing error while the actuator is saturated and cannot respond, so when the limit releases the controller commands a large, delayed overcorrection. Anti-windup logic (including freezing the integrator on saturation) is the standard remedy, which is why the alarm is a natural place to trigger it. ↩