3、故障注入技术基础

各位同学好，我是老张。今天咱们聊聊故障注入技术的基础。说实话，我刚入行那会儿，对故障注入的理解就是「把系统搞坏看看它会不会死」。后来吃了不少亏，才明白这里面门道很深。

故障注入，说白了就是主动给系统制造麻烦。你想想看，飞机在天上飞，双余度飞控系统要是遇到传感器坏了、总线断了、CPU死机了，它能不能自己扛过去？我们不可能真把飞机飞上天去测试这些故障，所以得在地面上模拟。

我个人习惯把故障注入分成三大类：硬件注入、软件注入、仿真注入。这三类各有各的玩法，也各有各的坑。我一个个说。

3.1 硬件注入

硬件注入是最「暴力」的方式。直接动手脚，让硬件出问题。

• 引脚短路/开路：拿镊子把芯片引脚短接一下，或者干脆剪断一根线。我在项目中遇到过，有一次测试时不小心把飞控板的SPI总线引脚碰短路了，结果整个传感器数据全乱了。嗯，那次之后我就养成了用绝缘胶带保护测试点的习惯。
• 电源扰动：给供电线上叠加一个尖峰脉冲，或者突然掉电再恢复。说白了就是模拟飞机上电源不稳的情况。
• 电磁干扰：用电磁枪对着飞控板打几下，看看它会不会死机。这个我建议新手别乱试，容易把板子打废。
• 温度/振动：把飞控板放进高低温箱或者振动台上。我记得有一次做高温测试，板子到85°C时陀螺仪数据就开始飘了，后来发现是焊点虚焊。

3.2 软件注入

软件注入就温柔多了。不需要动硬件，直接在代码层面动手脚。

常见的软件注入方式有：

1. 修改内存数据：比如把传感器采集到的数值强行改成异常值。我常用的做法是在驱动层加一个hook函数，拦截数据后篡改它。
2. 注入异常中断：模拟CPU收到一个非法中断，或者让某个任务陷入死循环。你想想看，如果飞控的导航任务突然卡死了，余度切换能不能及时顶上？
3. 篡改通信数据：在CAN总线或ARINC429总线上插入错误帧。说白了就是模拟总线被干扰的情况。
4. 模拟资源耗尽：把内存占满，或者把CPU利用率拉到100%。看看系统会不会崩溃。

这里我分享一个避坑指南：我曾经在软件注入时，直接修改了飞控的全局变量，结果导致系统进入了未定义状态，连看门狗都没救回来。后来我学乖了，每次注入前先备份关键数据，并且设置一个「安全回滚」机制。

3.3 仿真注入

仿真注入是我个人最喜欢的方式。它不需要真实的硬件，在仿真环境里就能完成大部分测试。

仿真注入的优势很明显：

• 成本低：不用买昂贵的硬件故障注入设备。
• 可重复：同样的故障可以反复注入，方便对比结果。
• 无风险：不会烧板子，随便折腾。

常用的仿真注入工具包括：

工具名称	适用场景	我的评价
Simulink + Fault Injection Toolbox	模型级故障注入	上手快，适合算法验证
QEMU + GDB	嵌入式软件级注入	灵活，但配置麻烦
VxWorks/RTEMS 仿真器	实时操作系统级注入	专业，但贵
自研仿真平台	定制化需求	最灵活，但开发周期长

3.4 故障注入工具介绍

说到工具，市面上有不少成熟的方案。我挑几个常用的说说。

硬件注入工具：

• 故障注入箱：比如Spirent的GSS系列，可以模拟各种总线故障。价格嘛，一台够买辆小汽车了。
• 可编程电源：用来模拟电源波动。我常用的是Chroma的电源，精度高，响应快。
• 信号发生器：用来注入噪声或干扰信号。比如Keysight的33500系列。

软件注入工具：

• FaultSim：一个开源的故障注入框架，支持在Linux内核层面注入故障。我试过，挺好用的。
• GDB + Python脚本：自己写脚本，通过GDB修改内存或寄存器。灵活度最高，但需要你会写代码。
• JTAG调试器：比如Lauterbach的Trace32，可以直接操作CPU寄存器。嗯，这个工具很强大，但价格也不便宜。

仿真注入工具：

• MATLAB/Simulink：自带故障注入模块，适合做算法级的验证。
• QEMU：开源的仿真器，可以模拟ARM、x86等架构。我经常用它来测试飞控的启动流程。
• Proteus：可以仿真单片机的外设故障，比如ADC通道损坏、PWM输出异常等。

3.5 知识体系总览

下面这张图是我自己画的，把故障注入的整个知识体系串起来了。你一看就明白。

这张图把故障注入的三大分类和各自的子项都列出来了。你仔细看看，会发现一个规律：越往左越「硬」，越往右越「软」。硬件注入最接近真实故障，但风险也最大；仿真注入最安全，但可能漏掉一些硬件层面的问题。

我个人建议的路线是：先仿真注入把逻辑验证通，再用软件注入测试边界条件，最后用硬件注入做最终确认。这样既高效又稳妥。

---

公众号:蓝海资料掘金营，微信deep3321