3、故障注入理论基础：故障模型分类与注入方法
各位同学，咱们今天聊点硬核的——故障注入的理论基础。说实话，很多做HIL测试的工程师，一上来就想着怎么把故障“怼”进去，却忽略了最根本的问题：你到底要模拟什么故障？
我见过不少项目，测试用例写了一大堆，结果跑下来发现，80%的故障都是重复的，还有20%根本不可能在实际车上发生。这就是典型的“没有理论指导的实践”。所以，咱们先把故障模型和注入方法理清楚，后面做设计才能有的放矢。
3.1 故障模型分类——你得知道“坏”在哪里
故障模型，说白了就是给“故障”分个类。你想想看，一辆车上的电子系统那么复杂，故障可能出现在任何地方。如果不分类，测试就是一团乱麻。
我个人习惯把故障模型分成四大类：电气、通信、传感器、执行器。这四类基本覆盖了HIL测试中90%以上的场景。
3.1.1 电气故障
这是最基础、也最容易复现的一类。我在项目中遇到过最典型的案例：一个ECU的电源引脚虚焊，导致车辆在颠簸路面上偶发重启。这种问题，用HIL台架模拟电源抖动就能复现。
| 故障类型 | 描述 | 典型场景 |
|---|---|---|
| 短路 | 信号线与电源或地线短接 | 线束磨损、进水 |
| 断路 | 信号线断开 | 插头松动、线缆断裂 |
| 过压/欠压 | 供电电压超出正常范围 | 发电机调节器故障、电池亏电 |
| 纹波干扰 | 电源上叠加交流分量 | 大功率负载切换、DC-DC转换 |
3.1.2 通信故障
现在的车，说白了就是“轮子上的计算机网络”。CAN、LIN、FlexRay、以太网……通信一旦出问题，整个系统都可能瘫痪。
我记得有一次，一个客户抱怨说他们的BMS（电池管理系统）在低温下会报通信超时。我们一开始以为是硬件问题，后来在HIL台架上注入CAN总线负载率过高的情况，才发现是软件处理不过来。嗯，这就是典型的通信故障。
- 位错误：总线上的显性/隐性电平冲突
- 帧错误：CRC校验失败、格式错误
- 超时故障：节点未在规定时间内发送报文
- 总线关闭：节点因错误过多主动退出总线
- 信号无效：数据域中的信号值超出合理范围
3.1.3 传感器故障
传感器是ECU的“眼睛”和“耳朵”。传感器坏了，ECU就是“盲人摸象”。
我做过一个项目，测试的是自动紧急制动（AEB）系统。毫米波雷达在雨天会出现信号衰减，导致目标检测距离缩短。我们在HIL台架上模拟了雷达信号的衰减和噪声，结果发现系统在50km/h以上时制动响应慢了200ms——这个发现直接推动了算法优化。
| 故障模式 | 模拟方法 | 典型影响 |
|---|---|---|
| 漂移 | 在真实信号上叠加缓慢变化的偏移量 | 测量值逐渐偏离真实值 |
| 卡滞 | 保持输出值不变 | ECU认为信号“冻结” |
| 噪声 | 叠加高斯白噪声或脉冲噪声 | 信号信噪比下降 |
| 比例误差 | 乘以一个增益系数（如1.2倍） | 测量值成比例偏差 |
3.1.4 执行器故障
执行器是ECU的“手脚”。你想想看，ECU发出指令了，但执行器没反应或者反应慢了，那后果可能很严重。
我曾经测试过一个电子水泵的控制策略。在HIL台架上，我们模拟了水泵“卡死”的故障——电机堵转，电流飙升。结果发现，ECU的诊断策略在3秒后才报出故障，而这段时间内冷却液温度已经上升了15度。嗯，这个案例告诉我们：执行器故障的诊断响应时间，必须和系统热惯性匹配。
- 卡死：执行器无法动作（如阀门卡在某个位置）
- 响应延迟：执行器动作时间超出标定值
- 行程受限：执行器无法达到全行程
- 回差过大：正向和反向动作的间隙过大
3.2 故障注入方法——怎么把故障“放”进去
故障模型有了，接下来就是怎么把故障注入到系统中。我把它分成三个层面：硬件层、软件层、数据层。这三个层面各有优劣，实际项目中往往是组合使用。
3.2.1 硬件注入
这是最“物理”的方法。说白了，就是用真实的硬件设备去改变电气特性。
我早期做HIL测试时，用的就是继电器矩阵+电阻箱。那时候设备笨重，但胜在可靠。现在很多HIL系统都集成了故障注入板卡（FIU），方便多了。
// 硬件注入示例：通过继电器控制信号通断
// 伪代码示意
FIU_Channel ch1 = FIU_OpenChannel("ECU_PIN_12"); // 打开通道
FIU_SetState(ch1, FIU_OPEN); // 断开信号线（模拟断路）
Delay_ms(500); // 保持500ms
FIU_SetState(ch1, FIU_CLOSE); // 恢复连接
FIU_CloseChannel(ch1);3.2.2 软件注入
软件注入，就是在ECU的软件层面动手脚。比如修改标定参数、篡改内存值、或者直接修改函数返回值。
我个人比较喜欢软件注入，因为它灵活。你想想看，一个HIL台架上可能同时跑着十几个ECU的模型，如果每个都要用硬件注入，那成本得翻几倍。但软件注入也有风险——它可能改变ECU的正常行为，导致测试结果失真。
// 软件注入示例：修改传感器返回值
// 假设有一个函数 GetWheelSpeed()
// 我们通过注入代码，让它返回一个固定值
float GetWheelSpeed_Injected(void) {
// 原始代码
// return ReadSensorValue();
// 注入后的代码
if (fault_active) {
return 0.0f; // 模拟传感器卡滞在0
} else {
return ReadSensorValue();
}
}3.2.3 数据层注入
数据层注入，是在通信层面动手脚。比如修改CAN报文中的某个信号值，或者篡改LIN的调度表。
我记得有一次，我们需要测试一个网关的转发逻辑。硬件注入太麻烦，软件注入又涉及到底层代码。最后我们选择了数据层注入——直接在CAN总线上插入一个“中间人”节点，实时篡改报文内容。效果出奇的好。
| 注入方式 | 实现手段 | 适用场景 |
|---|---|---|
| CAN信号篡改 | 修改DBC文件中的信号值 | 传感器值、状态位 |
| 报文插入/删除 | 在总线上额外发送或屏蔽报文 | 通信超时、丢失报文 |
| 时序扰动 | 改变报文的发送周期 | 抖动、延迟测试 |
| CRC/校验错误 | 故意发送错误校验码 | 诊断策略验证 |
3.3 三种方法的对比与选择
你可能会问：这三种方法，到底选哪个？我的回答是：看你的测试目标。
- 硬件注入：适合验证硬件接口、线束、连接器的可靠性。比如你要测一个ECU的电源管理策略，那硬件注入是首选。
- 软件注入：适合验证软件逻辑、诊断策略、故障处理机制。比如你要测一个传感器的合理性检查，软件注入更高效。
- 数据层注入：适合验证通信协议、网络管理、网关转发。比如你要测CAN总线的负载率对系统的影响，数据层注入最直接。
好了，这一节的内容就到这里。故障模型和注入方法是HIL测试的“基本功”，看似简单，但真正用好的人不多。你想想看，如果你连故障都分不清、注入方法都选不对，那后面的测试结果能有多大的参考价值？
下一节我们会聊到具体的故障注入用例设计，到时候我会结合几个实际项目案例，带大家走一遍完整的流程。
公众号:蓝海资料掘金营，微信deep3321