📚 课程目录第4章基于断点的故障注入

4、基于断点的故障注入：利用IDE断点修改变量值

断点，大家平时都用它来调试。但你知道吗？它也是故障注入的一把利器。

我个人习惯把断点分为两类：一类是观察型断点，只看不停；另一类是干预型断点，停下来后，我手动改数据、改状态、甚至改程序流。今天要聊的，就是后者。

4.1 为什么用断点做故障注入？

你想想看，传统的故障注入要改代码、重新编译、下载，一套流程下来，十分钟过去了。而断点注入呢？

快：在IDE里双击设断点，运行到那，改个值，继续跑。前后不到30秒。
准：你想在哪个函数、哪一行、哪个变量上动手脚，完全可控。
无侵入：不改一行源代码，不污染固件镜像。

我在项目中遇到过一种情况：某个传感器信号偶尔丢失，但概率极低，跑一整天可能才复现一次。用断点注入，我直接在采集函数入口把变量值改成0xFFFF（无效值），几秒钟就能验证ECU的故障响应逻辑对不对。

  核心思想：断点注入的本质是“在正确的时间点，把正确的错误值，塞进正确的变量里”。

4.2 断点注入的三种手法

根据IDE的不同，手法略有差异。但万变不离其宗，我总结了三类：

手法	操作方式	适用场景
手动修改	断点命中后，在Variables窗口直接改值	单次、探索性测试
条件断点	设置命中次数或表达式，自动触发修改	需要重复注入的场景
脚本化断点	用IDE脚本（如GDB Python、Trace32 PRACTICE）自动执行修改	回归测试、批量注入

嗯，这里要注意：手动修改虽然灵活，但容易手抖。我曾经在一次演示中，本来想改0x00，结果敲成了0x01，导致ECU进入了错误的状态机分支，排查了半天才发现是注入值敲错了。

我的建议：如果是正式测试，尽量用脚本化断点。把注入值、注入时机、恢复逻辑都写清楚，可复现、可追溯。

4.3 实战：模拟传感器信号丢失

好，理论说完了，咱们直接上手一个真实案例。

场景：某BMS（电池管理系统）的温度传感器，正常范围是-40°C ~ 125°C。当传感器开路或短路时，ADC会读到0xFFFF（16位满量程）。ECU需要在100ms内检测到故障，并进入降级模式。

我们要做的，就是在代码中模拟这个“0xFFFF”的出现。

4.3.1 找到注入点

先看代码结构。通常传感器采集流程是这样的：

// 温度采集任务，10ms周期执行
void TempSensor_Task(void)
{
    uint16_t adc_raw;
    float temperature;

    // 步骤1：读取ADC寄存器
    adc_raw = ADC_ReadChannel(ADC_CH_TEMP);

    // 步骤2：原始值转物理量
    temperature = ADC_To_Temperature(adc_raw);

    // 步骤3：故障检测
    if (adc_raw == 0xFFFF) {
        SetFaultFlag(FAULT_TEMP_SENSOR_LOST);
        EnterSafeMode();
    } else {
        UpdateTemperature(temperature);
    }
}

注入点选在哪里？我个人习惯选在步骤1之后、步骤2之前。为什么？因为此时adc_raw刚被赋值，我们把它改成0xFFFF，后续的故障检测逻辑就会原封不动地被触发。

4.3.2 设置断点并修改

以IAR Embedded Workbench为例：

在 adc_raw = ADC_ReadChannel(ADC_CH_TEMP); 这一行设断点。
全速运行程序，断点命中。
在Watch窗口找到 adc_raw，右键 → Modify，输入 0xFFFF。
按F5继续运行。

就这么简单。ECU会立刻检测到adc_raw == 0xFFFF，然后设置故障标志、进入安全模式。

注意：修改完变量后，一定要确认IDE是否允许“修改后继续执行”。有些IDE（比如某些版本的Keil）在断点处修改局部变量后，优化器可能会把值覆盖掉。我建议你在修改后，单步执行一行，确认新值生效了再全速跑。

4.3.3 验证结果

跑完注入后，我们需要检查三件事：

故障标志位：FAULT_TEMP_SENSOR_LOST 是否被置位？
安全模式：ECU是否在100ms内进入了降级模式？
非预期影响：其他模块（比如电压采集、通信）有没有被连带影响？

我记得有一次，注入后ECU确实进入了安全模式，但CAN通信也停了。后来发现是安全模式代码里直接调了 CAN_Stop()，导致整车网络中断。这个bug如果不通过断点注入，很难在单元测试阶段发现。

4.4 断点注入的局限性

说实话，断点注入不是万能的。它有明显的短板：

时序敏感：断点命中会暂停CPU，改变了实时性。如果故障响应依赖精确的时序（比如PWM占空比），断点注入可能会掩盖问题。
无法注入硬件级故障：比如引脚短路、时钟抖动，断点改不了。
多核/多ECU场景麻烦：一个核停了，其他核可能超时或报错。

所以我的经验是：断点注入适合功能逻辑验证和故障响应路径的快速覆盖。但到了硬件在环（HIL）阶段，还是得上专业的故障注入单元（比如IO卡件短路/开路）。

4.5 本章知识图谱

下面这张图，帮你把断点注入的完整流程串起来：

4.6 小结

断点注入，说白了就是“在正确的地方，手动制造一个错误”。它不需要改代码、不需要额外硬件，是SIL测试阶段性价比最高的故障注入手段之一。

但记住：它只能验证软件逻辑的正确性。硬件层面的故障，还是得交给HIL去干。