Rate Limiting & Quotas for Actuation
Even valid commands are throttled to engineering slew limits and per-actuator quotas so no burst can drive hardware faster than it may move.
Fast is not always safe
A command can be schema-valid, rule-legal, and inside the envelope, yet still be dangerous if issued too fast or too often. Superconducting magnets have slew limits; gas valves and heating systems have duty limits. The actuation rate limiter enforces these as a distinct gate, independent of throughput, so a flood of individually-legal setpoints cannot exceed hardware slew on the breeder coils or the burner plug magnet.
Token-bucket per actuator
class SlewGuard:
def allow(self, actuator, new_sp, now):
max_delta = SLEW_MAX[actuator] * (now - self.last_t[actuator])
if abs(new_sp - self.last_sp[actuator]) > max_delta:
return CLAMP_OR_REJECT # never exceed hardware slew
if not self.bucket[actuator].take(1, now):
return REJECT # per-actuator command-rate quota
self._commit(actuator, new_sp, now); return OK
Slew clamping vs rejection
- For continuous setpoints (coil current, plug field toward 26.49 T) an over-fast command is clamped to the max legal slew, not silently dropped.
- For discrete actions (a gas puff) an over-quota command is rejected and surfaced.
- Every clamp and reject is logged so the copilot can learn it is asking for impossible rates.
Interaction with safety
Rate limiting complements but does not replace the envelope: the envelope says where the machine may be, the rate limiter says how fast it may move between legal points. Both are on the gating path. Emergency safe-state actions (abort ramps) use rate limits set for controlled but rapid de-energize, not the routine slew caps.
Quotas protect shared systems
Per-actuator and per-subsystem quotas also protect shared services such as fuelling and heating from being monopolized by one runaway procedure, working with backpressure and the scheduler to keep the machine responsive to higher-priority needs.