2、故障模型与分类：硬件故障、软件故障、系统性故障与随机硬件故障

各位工程师朋友，咱们今天聊聊故障模型与分类。说实话，这是功能安全测试的根基。你连故障长什么样都不知道，怎么去注入它？怎么去验证安全机制好不好使？

我个人习惯把故障分成四大类：硬件故障、软件故障、系统性故障、随机硬件故障。这四类故障，我在项目里都踩过坑。今天我把它们掰开揉碎了讲给你听。

2.1 硬件故障：单点故障与潜伏故障

硬件故障，说白了就是芯片、电阻、电容这些物理器件出了问题。我最早做ECU测试时，总觉得硬件很可靠。直到有一次，一个电源芯片的引脚虚焊，车子跑着跑着就重启了。嗯，从那以后我再也不敢小看硬件故障了。

硬件故障里，我最关注两类：

• 单点故障：一个硬件坏了，直接导致安全目标被违反。比如刹车踏板的传感器坏了，你踩刹车没反应。这就是单点故障。
• 潜伏故障：故障本身不直接导致危险，但它让安全机制失效了。比如看门狗电路坏了，但系统还在跑。等真正需要看门狗复位时，它不工作了。这就叫潜伏故障。

我在项目中遇到过一件事：一个ECU的ASIL C设计，单点故障度量算出来只有85%，离目标90%差一截。后来发现是一个输出驱动芯片的故障没有被覆盖。加了一个诊断回路，才把指标拉上去。

2.2 软件故障：内存故障与逻辑故障

软件故障，嗯，这个大家应该不陌生。做嵌入式开发的，谁没被野指针、数组越界折磨过？

我把软件故障分成两类：

2.2.1 内存故障

内存故障包括：

• RAM故障：位翻转、地址线短路、数据线粘连。你想想看，一个关键变量的值突然变了，系统会怎么表现？
• Flash/ROM故障：程序代码被篡改、校验和错误。我见过一个案例，Flash里的一段代码因为老化变成了0xFF，结果程序跑飞了。
• 堆栈溢出：递归调用太深，或者中断嵌套太多，堆栈把别的变量区给覆盖了。

2.2.2 逻辑故障

逻辑故障，说白了就是代码写错了。比如：

• 条件判断错误：if-else写反了，或者边界条件没处理好
• 时序逻辑错误：状态机跳转条件不对，或者超时处理没做
• 数据流错误：变量赋值顺序搞反了，或者数据被意外覆盖

我记得有一次，一个同事写的刹车控制逻辑，在某个特定条件下会跳过安全校验。代码review了三轮都没发现，最后是故障注入测试时抓到的。所以说，代码review不是万能的，故障注入才是硬道理。

2.3 系统性故障与随机硬件故障

这两类故障，是ISO 26262里最核心的分类。我经常被问到："它们到底有什么区别？"

对比项	系统性故障	随机硬件故障
产生原因	设计错误、制造缺陷、使用不当	硬件老化、环境应力、随机事件
发生规律	可复现，相同条件下必然发生	随机发生，服从概率分布
消除方式	修改设计、改进流程	增加冗余、诊断覆盖
典型例子	软件bug、时序冲突、需求遗漏	芯片位翻转、焊点疲劳、电容漏电

为什么会这样？因为系统性故障是"人"的问题，你改对了就没了。随机硬件故障是"物理"的问题，你只能降低概率，不能完全消除。

2.4 故障模型在测试中的应用

讲完了分类，咱们聊聊怎么用。我个人习惯把故障模型和测试策略对应起来：

1. 单点故障 → 用故障注入工具直接注入，验证安全机制能否检测并响应
2. 潜伏故障 → 注入故障后，让系统运行一段时间，看诊断是否能在规定时间内发现
3. 内存故障 → 用内存测试算法（如March C+）或者直接篡改内存值
4. 逻辑故障 → 通过代码插桩、条件翻转来模拟
5. 系统性故障 → 靠代码review、静态分析、形式化验证
6. 随机硬件故障 → 靠FMEDA分析，然后针对高故障率的器件做针对性测试

你想想看，如果你连故障模型都分不清，你怎么设计测试用例？怎么评估覆盖率？

好了，这一章的内容就到这里。下一章我会讲故障注入的具体方法和工具选择。到时候我会分享一些我在实际项目中用过的工具和踩过的坑。

记住一句话：故障模型是测试的蓝图，分类是测试的指南针。把这两样东西搞清楚了，你的功能安全测试就成功了一半。