---
tags: []
date created: 星期五, 十一月 21日 2025, 3:15:00 下午
date modified: 星期一, 十一月 24日 2025, 4:31:51 下午
---

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

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

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

1. **触发源单一性**：仅响应**物理传感器告警**（温度、功耗）。显控 UI 操作不再作为触发源。
2. **响应滞后性 (Hysteresis)**：热惯性是缓慢的。控制逻辑必须包含**迟滞（Hysteresis）**机制，防止在阈值附近频繁切换导致系统震荡（Flapping）。
3. **执行确定性**：节流动作必须是**确定性的降速**（如每帧固定休眠），而非不确定的丢包。丢包应由上游的背压机制（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` 组件。
- **逻辑**：

    ```cpp
    // 伪代码：迟滞状态机
    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` 的主循环末尾。
- **实现**：

    ```cpp
    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 系统负载保护** 的基线：

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

下一步建议：

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

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

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