2. 故障注入基础理论：故障模型分类、注入时机、测试策略
各位工程师朋友，咱们进入第二章。这一章是地基，打不牢后面全白搭。故障注入不是拿个工具瞎捅两下就完事，你得知道捅哪里、什么时候捅、捅完看什么。我见过太多人上来就怼着ECU一顿乱搞，最后报告写得跟天书似的，老板一问三不知。
说白了，故障注入测试的核心就三件事：故障模型怎么分、什么时候注入、策略怎么定。咱们一个一个掰开讲。
2.1 故障模型分类
故障模型，就是你要模拟的“坏掉的样子”。线控转向系统里，故障不是随便来的，得按标准来。我个人习惯按ISO 26262和SAE J3016的框架分，但实际项目中我会再细化一层。
核心分类法：按故障的表现形式和影响范围分，别按故障原因分。原因你管不了，表现你测得到。
2.1.1 按故障表现形式
| 故障类型 | 典型表现 | 线控转向实例 |
|---|---|---|
| 硬故障 | 信号永久丢失、短路、断路 | 手轮角度传感器完全无输出 |
| 软故障 | 信号漂移、噪声、间歇性中断 | 电机位置反馈偶尔跳变几个LSB |
| 时序故障 | 延迟、抖动、超时、乱序 | CAN报文延迟超过50ms |
| 逻辑故障 | 状态机跑飞、校验错误、协议异常 | CRC校验持续失败 |
嗯，这里要注意。硬故障好测，一抓一个准。真正恶心的是软故障和时序故障。我在项目里遇到过，一个传感器信号漂移了2%，系统没报错，但方向盘回正时总差那么一度。查了三天，最后发现是温度漂移导致的软故障。所以，软故障才是功能安全的大头。
2.1.2 按故障影响范围
- 单点故障：一个元件坏了，系统还能撑一会儿。比如一个电机绕组断路，另一个还能转。
- 多点故障：两个以上元件同时坏。比如传感器和备份传感器一起漂移。
- 共因故障：一个原因导致多个地方坏。比如电源过压烧了一片芯片。
- 级联故障：一个坏了引发另一个也坏。比如电机堵转导致驱动芯片过热烧毁。
我的经验：共因故障最容易漏测。你想想看，两个冗余传感器装在同一块PCB上，一个电源纹波大，两个一起漂。你测单点故障时都过了，但共因一来直接跪。所以，故障模型分类时，一定要把共因单独列出来。
2.2 注入时机
什么时候注入故障？不是你想什么时候就什么时候。时机选错了，测试结果等于废纸。我把它分成三个维度：系统状态、工况阶段、时间窗口。
2.2.1 系统状态维度
- 上电初始化阶段：注入故障看系统能不能正确自检并进入安全状态。
- 正常运行阶段：注入故障看系统能不能实时检测并降级。
- 降级运行阶段：注入故障看系统在降级模式下还能不能撑住。
- 下电阶段：注入故障看系统能不能安全关机。
我曾经犯过一个错。测试时只在系统稳定运行时注入故障，结果发现上电阶段有个故障根本检测不到。后来查出来，初始化时序里有个窗口期，故障检测模块还没启动。所以，每个状态都要覆盖，别偷懒。
2.2.2 工况阶段维度
| 工况 | 注入时机 | 关注点 |
|---|---|---|
| 直线行驶 | 稳态时注入 | 系统能否保持方向不偏 |
| 转弯过程 | 转向中注入 | 力矩输出是否突变 |
| 紧急避障 | 高动态时注入 | 响应时间是否超标 |
| 泊车工况 | 低速大角度时注入 | 末端保护是否触发 |
避坑指南：我曾经在转弯过程中注入了一个电机扭矩故障，结果系统直接切到备份模式，方向盘瞬间变重。驾驶员差点失控。所以，高动态工况下注入故障，一定要先评估安全风险，最好用硬件在环（HIL）先跑一遍。
2.2.3 时间窗口维度
这个维度很多人忽略。故障注入不是持续怼着，你得选关键时间窗口：
- 故障检测窗口：系统检测故障需要时间，你在检测窗口内注入，看它能不能及时响应。
- 故障反应窗口：系统检测到故障后，执行降级动作需要时间，你在反应窗口内注入第二个故障，看它会不会乱。
- 故障恢复窗口：故障消失后，系统恢复需要时间，你在恢复窗口内再次注入，看它能不能正确处理。
说白了，就是卡着时间点搞事情。我建议用故障注入时序图来规划，别凭感觉。
2.3 测试策略
策略决定了你怎么测、测多少、测到什么程度算完。我一般分三步走：基于风险的策略、基于覆盖率的策略、基于场景的策略。
2.3.1 基于风险的策略
先评估风险。ASIL等级高的功能，多测；等级低的，少测。线控转向里，手轮转角传感器和电机位置传感器通常是ASIL D，那就得往死里测。而一些辅助功能，比如方向盘加热，ASIL A，测几个典型故障就行。
核心原则：故障注入的深度和广度，与ASIL等级成正比。别在低风险功能上浪费太多时间。
2.3.2 基于覆盖率的策略
覆盖率不是代码覆盖率，是故障模型覆盖率。你得问自己：我列的故障模型，测了多少？
| 覆盖率等级 | 要求 | 适用场景 |
|---|---|---|
| L1 基础覆盖 | 每个故障类型至少测1个实例 | 快速验证、冒烟测试 |
| L2 全面覆盖 | 每个故障类型测所有关键实例 | 功能安全认证测试 |
| L3 深度覆盖 | 组合故障、边界条件、极端工况 | 量产前最终验证 |
我建议至少做到L2。L3看项目预算和时间，但别低于L2，否则认证过不了。
2.3.3 基于场景的策略
这个策略最贴近实际。你把故障放到真实场景里测，而不是孤立地测一个信号。比如：
- 场景一：高速行驶中，手轮角度传感器突然失效，系统切换到备份传感器，看方向盘会不会抖动。
- 场景二：泊车时，电机位置反馈出现间歇性噪声，看系统能不能滤波掉。
- 场景三：连续急转弯时，CAN总线负载达到80%，此时注入一个报文丢失故障，看系统能不能扛住。
我的习惯：先做基于风险的策略，确定测什么；再做基于覆盖率的策略，确定测多少；最后用基于场景的策略，确定怎么测。三个策略叠加，基本不会漏。
2.4 知识体系总览
下面这张图，把咱们刚才讲的三块内容串起来了。你保存下来，以后做测试方案时对着看。
这张图把故障模型分类、注入时机、测试策略串成了一个整体。你以后做测试方案时，对着这张图问自己三个问题：我分类全了吗？时机选对了吗？策略够狠吗？三个都答“是”，这章你就过关了。