BMS HIL 故障注入怎么做：从模型分层到可验收的测试闭环

hyowinner

BMS HIL 故障注入怎么做：从模型分层到可验收的测试闭环

做 BMS HIL 时，最容易出现的误区是：在台架上把一个变量改成异常值，看到故障标志置位，就认为故障注入通过了。这个结果最多说明某段诊断逻辑能被触发，不能说明 BMS 在真实接口、真实任务周期和真实系统状态下会按需求保护。

一条能交付的 BMS HIL 故障注入用例，至少要回答五个问题：故障从哪里进入、何时被确认、BMS 做了什么动作、诊断记录了什么、故障消失后如何恢复。MBD 的价值在于把这些问题提前固化成模型接口、状态机、标定量和可自动执行的判定规则。

图 1：BMS HIL 台架中，实时模型、故障插入层、被测 BMS 和测试证据需要构成闭环。

一、先定义 HIL 故障注入的边界

BMS HIL 的被测对象通常是 BMS ECU、其应用软件或自动生成代码；实时仿真机承担电芯、温度、电流、高压回路、接触器、绝缘和网络节点的等效模型；测试框架负责触发故障、采集信号、执行诊断服务和给出判定。

关键原则是：故障应尽量从被测件实际使用的接口进入。电压、温度、电流类故障通过模拟量或等效采样接口进入；CAN 类故障通过总线模型或网络仿真进入；接触器拒动、粘连等故障通过反馈回路和电气模型进入。直接把 BMS 内部的 `Fault_OV` 或 `ContactorWelded` 强制置位，可以用于模型单元测试，但不能替代 HIL 验收。

同样需要区分“受控故障插入”和“手工制造异常”。涉及高压、硬线短路、接触器功率回路或外部供电的场景，应在具备互锁、限能、急停和自动复位能力的受控台架上完成。不要以手工断线、临时短接来替代可记录、可重复的故障通道。

二、BMS HIL 最常见的四类故障

第一类是 采样与传感器故障。包括单体电压越界、采样偏置、NTC 开路或短路、电流传感器跳变、绝缘值异常等。重点不只是看范围诊断是否置位，还要看故障去抖、替代值、均衡使能、充放电允许值和保护阈值是否符合需求。

第二类是 通信与数据完整性故障。典型场景有报文丢失、周期变慢、延迟、重复、alive counter 错误、CRC/E2E 错误、节点离线和网络负载升高。这里要把“收到一帧异常”与“通信故障成熟”分开：Data Age、连续错误计数、超时门限、恢复所需有效帧数都应清楚定义。

第三类是 执行器与反馈故障。例如预充失败、主接触器拒动、主接触器粘连、辅助触点反馈不一致、均衡 MOS 反馈异常、冷却请求未响应。这一类必须验证命令和反馈闭环。BMS 发出断开命令并不等于高压系统已经安全断开，模型和台架都要能提供可信的反馈证据。

第四类是 工况与电气模型故障。包括过流、SOC 边界、母线压差、绝缘下降、充放电状态切换和多个故障同时出现。这类场景特别适合检验故障仲裁：当通信超时与绝缘异常同时存在时，哪一个动作优先？当系统从充电切到下电时，已经成熟的故障是自动恢复、延迟恢复，还是锁存等待诊断清除？

图 2：故障用例要将注入点、使能条件、成熟边界、保护动作、证据与恢复规则写在同一张矩阵中。

三、把故障插入层建成模型接口，而不是散落的开关

推荐在实时模型与 ECU 接口之间设置独立的 Fault Injection Layer。每个故障通道至少有四类参数：使能、开始时刻或触发条件、故障强度、结束条件。例如温度故障不是只用一个 `TempFaultEnable`，而是可以选择保持值、偏置、阶跃、开路等模式，并记录真实注入的电压、电阻或换算温度。

通信故障也不建议只设置一个 `CanTimeout=1`。更符合实际的做法是在通信模型中实现丢帧、延迟、重复、计数器冻结、CRC/E2E 错误和总线负载变化，让 BMS 自己的接收、校验和超时逻辑经历完整链路。这样既能避免测试绕过关键软件，也能暴露任务周期和网络时序带来的边界问题。

在 Simulink 或 Stateflow 架构中，故障插入层应和电池模型、BMS 软件模型、测试激励模型分开。故障模型输出的是“异常后的接口值”，诊断模型输出的是“事件状态”，动作仲裁输出的是“保护请求”。边界清楚后，才能在 MIL、SIL 与 HIL 间复用用例，而不让每个阶段各自维护一套故障逻辑。

四、用时间轴验收，不要只看最终状态

一个故障用例至少应记录以下节点：t0 为正常运行基线；t1 为故障开始注入；t2 为 BMS 检测或成熟；t3 为保护动作生效；t4 为停止注入；t5 为恢复完成或进入锁存状态。最终报告应给出 `t2-t1` 的检测延迟、`t3-t2` 的动作延迟和 `t5-t4` 的恢复时间，并与需求或标定值对应。

以 NTC 开路为例，不能只看温度故障 DTC 是否产生。完整判定至少包括：故障持续时间略小于确认阈值时不成熟；超过确认阈值后事件状态变化正确；均衡是否被禁止；充放电允许值是否按等级收紧；DTC 和冻结数据是否能被读取；恢复后是否要求连续有效采样，还是需要钥匙循环或诊断清除。

以 CAN 数据失效为例，还要分清发送方归属。如果由 HIL 网络模型发送 BMS 的外部依赖报文，可以通过停发、延迟或损坏报文实现真实超时；如果 BMS 自己就是发送方，单纯在旁路监听口停止发送并不会让 BMS 的原始报文消失。测试拓扑必须能解释故障作用在哪一段链路，避免把观察结果误当成注入结果。

图 3：把注入、检测、控制、诊断和恢复放在统一时基上，才能定位阈值、任务周期和状态机问题。

五、建议优先建立的最小用例集

1. 正常基线：稳定运行、模式切换、上下电和网络唤醒阶段均不应误报。
2. 单体过压或欠压：覆盖阈值前、阈值后、确认时间、保护请求、恢复阈值和锁存策略。
3. 温度传感器异常：覆盖开路、短路、偏置和跳变，验证均衡、充放电限制及替代温度。
4. 电流与绝缘故障：覆盖幅值、持续时间和与接触器状态相关的使能条件，验证严重故障优先级。
5. 通信数据失效：覆盖丢帧、延迟、E2E 错误和恢复有效帧数，验证 Data Age、降级和重新可信条件。
6. 接触器闭环故障：覆盖拒动、粘连、预充超时和反馈矛盾，验证命令、反馈、诊断和安全动作的一致性。
7. 组合故障：至少选取一个通信故障与一个高压安全故障并发的场景，验证仲裁优先级不会被后续逻辑覆盖。

六、HIL 结果怎样才算可交付

一条合格的 HIL 记录应能从同一测试编号追溯到需求、模型接口、标定版本、测试脚本和结果文件。证据不应只是一张故障灯截图，而应包括：故障注入参数和时间戳、原始输入与实时模型状态、BMS 内部事件状态或可观测等效信号、接触器和功率限制等控制输出、CAN Trace、DTC 或诊断服务响应，以及故障清除后的状态。

最值得避免的两种“假通过”是：第一，测试脚本直接改了 BMS 内部变量，绕过了采样、通信或诊断链路；第二，只在故障出现后截取最终状态，没有覆盖确认门限、动作延迟和恢复路径。前者无法证明集成接口正确，后者无法发现状态机和多速率任务中的边界缺陷。

结论

BMS HIL 故障注入的核心不是制造更多异常，而是让每一个异常都成为可控制、可观察、可复现的工程证据。先按接口划分故障入口，再用独立故障插入层表达时序和强度，最后以“注入-检测-动作-诊断-恢复”的完整时间轴验收，才能把 HIL 从演示工具变成支撑软件发布和问题定位的验证闭环。