2.3.5 系统负载保护与热节流控制 (System Load Protection & Thermal Throttling)

一、约束输入与对齐 (Constraints & Alignment)

基于变更后的架构目标，我们需对齐以下硬性约束：

触发源单一性：仅响应物理传感器告警（温度、功耗）。显控 UI 操作不再作为触发源。
响应滞后性 (Hysteresis)：热惯性是缓慢的。控制逻辑必须包含**迟滞（Hysteresis）**机制，防止在阈值附近频繁切换导致系统震荡（Flapping）。
执行确定性：节流动作必须是确定性的降速（如每帧固定休眠），而非不确定的丢包。丢包应由上游的背压机制（Backpressure）自然处理，而不是由计算模块主动丢弃。

二、权衡分析与选项呈现 (Trade-off Matrix)

议题 1：降级执行策略 (Throttling Execution)

选项	A. 丢弃任务 (Task Dropping)	B. 动态降频 (DVFS / Clock Gating)	C. 软件占空比控制 (Software Duty Cycle) (推荐)
机制	直接丢弃输入的 `DataContext`，不进行计算。	调用驱动 API (`ixsmi`) 强制降低 GPU 时钟频率。	在主处理循环中插入 `sleep()`，人为制造流水线气泡。
热效应	极好。GPU 完全空闲。	好。降低电压和频率。	可控。通过调整休眠时长精确控制负载率。
副作用	数据断层。破坏目标跟踪的连续性。	依赖驱动。智铠 SDK 可能未开放用户态调频接口，且响应慢。	延迟增加。但数据流保持连续，仅吞吐下降。
适用性	仅限 Level 3 (紧急停机)。	固件层保护（最后一道防线）。	应用层首选。通用、简单、不丢数据。

议题 2：控制回路设计 (Control Loop)

选项	A. 简单阈值 (Simple Threshold)	B. 迟滞比较器 (Hysteresis Comparator) (推荐)
机制	>90°C 降速，<90°C 恢复。	>90°C 降速 (Trigger)，<80°C 恢复 (Release)。
稳定性	差。会在 90°C 附近反复震荡，导致风扇啸叫和电流波动。	高。确保系统冷却到安全区间后才恢复全速。

三、基线确立与实施规范

为了在极端工况下保护硬件同时维持最低限度的业务连续性，我们确立 C. 软件占空比控制 + B. 迟滞比较器 为基线。

1. 交互协议基线 (Protocol)

定义一套闭环的保护协议：

告警事件 (Alert) - 由 MonitoringModule 发布：
- SystemOverloadEvent { Type: THERMAL | POWER; Level: WARNING | CRITICAL; Value: float; }
  - WARNING: 接近阈值（如 85°C）。
  - CRITICAL: 超过阈值（如 95°C）。
指令事件 (Command) - 由 ResourceCoordinator 发布：
- SetComputeThrottleEvent { ThrottleLevel level; TraceID trace_id; }

2. 节流分级定义 (Throttle Levels)

等级	定义 (Level)	行为规范 (Behavior)	目标负载 (GPU Usage)	触发场景
L0	NO_THROTTLE	全速运行，无额外休眠。	100% (Max)	温度 < 80°C
L1	LIGHT	每帧处理后休眠 5ms。	~80%	80°C < 温度 < 90°C
L2	HEAVY	每帧处理后休眠 20ms。	~50%	温度 > 90°C
L3	SUSPEND	暂停计算。停止从队列取数据（触发背压）。	0% (Idle)	温度 > 95°C (濒临宕机)

3. 迟滞控制逻辑 (Hysteresis Logic)

位置：TaskScheduler 中的 ResourceCoordinator 组件。

逻辑：

// 伪代码：迟滞状态机
void onTemperatureUpdate(float temp) {
    static State state = NORMAL;

    switch (state) {
        case NORMAL:
            if (temp > 90.0) { state = THRORRLE_L2; publish(LEVEL_2); }
            else if (temp > 85.0) { state = THRORRLE_L1; publish(LEVEL_1); }
            break;
        case THRORRLE_L1:
            if (temp > 90.0) { state = THRORRLE_L2; publish(LEVEL_2); }
            else if (temp < 75.0) { state = NORMAL; publish(LEVEL_0); } // 迟滞回落
            break;
        case THRORRLE_L2:
            if (temp < 80.0) { state = THRORRLE_L1; publish(LEVEL_1); } // 迟滞回落
            break;
    }
}

4. 模块侧实现规范

组件：在 SignalProcessor 中新增 ThrottleController 类。
侵入点：ExecutionEngine 的主循环末尾。

实现：

void ExecutionEngine::run() {
    while (running_) {
        // 1. 获取数据 & 2. 提交计算 (…原逻辑…)

        // 3. 节流控制点 (新增)
        throttle_controller_.applyDelay();
    }
}

void ThrottleController::applyDelay() {
    // 读取原子变量，避免锁竞争
    auto level = current_level_.load(std::memory_order_relaxed);
    if (level == L1) std::this_thread::sleep_for(5ms);
    else if (level == L2) std::this_thread::sleep_for(20ms);
    else if (level == L3) std::this_thread::sleep_for(100ms); // 轮询等待
}

总结与下一步行动

我们确立了 2.3.5 系统负载保护 的基线：

机制：软件级休眠 (Duty Cycle)，牺牲延迟换取降温。
策略：四级节流 + 迟滞控制，防止系统震荡。
触发：仅限 物理过载。

下一步建议：

控制面的“指挥”和“保护”都做好了。现在我们要解决最具挑战性的“动态调整”问题 —— 2.3.6 两阶段配置热更新协议。

比如，如何在雷达正在运转时，安全地把 CFAR 检测阈值从 15dB 改为 13dB，或者切换波束扫描策略，而不需要重启整个进程？这需要一套严密的事务协议。

提问：您是否确认 “四级节流 + 迟滞控制” 的保护基线？确认后我们将深入 2.3.6。

5.9 KiB Raw Permalink Blame History Unescape Escape