1. 课程导入与故障注入测试全景

在真实设备研发与运维中，最棘手的问题往往不是"设备坏了"，而是"设备在特定条件下才会坏"。例如某工业网关在低温启动时偶发通信中断，某车载控制器在电压跌落 200 ms 后 CAN 报文丢失，某边缘计算盒子在连续运行 72 小时后内存缓慢泄漏。这些问题如果只靠现场复现，成本高、周期长、随机性强。故障注入测试的核心价值，就是把这些"偶发、危险、昂贵"的故障，提前搬到实验室里，用可控、可重复、可观测的方式主动制造出来，从而验证设备的容错能力、恢复能力和安全边界。

本课程讨论的对象是"设备故障场景虚拟注入与测试"，它包含三个关键词。第一是故障场景：不是随意破坏，而是有明确触发条件、持续时间、影响范围和预期行为的故障描述。第二是虚拟注入：通过软件仿真、硬件在环、总线报文篡改、环境参数模拟等手段，在不真正损坏设备的前提下注入故障。第三是测试：注入之后必须采集响应数据，判断设备是否按设计预期降级、告警、切换或恢复。三者缺一不可，否则就退化成"搞破坏"而不是"做测试"。

目标、对象与边界

故障注入测试的目标可以归纳为四类：验证安全机制是否生效、评估故障容忍度、暴露隐藏缺陷、支撑认证与交付证据。以某电池管理系统（BMS）为例，目标是确认当单体电压采样线断路时，系统能否在 500 ms 内上报故障并禁止继电器闭合。这里的"500 ms"和"禁止闭合"就是可判定的目标，而不是模糊的"提高可靠性"。

测试对象通常包括：被测设备（DUT）本身、其传感器与执行器接口、通信总线、供电网络以及嵌入式软件。边界则需要明确哪些故障由本测试覆盖，哪些不在范围内。例如我们可以注入 CAN 报文丢失、电压跌落、温度传感器漂移，但不应注入会永久损坏硬件的过压击穿；后者属于破坏性试验，需要单独的安全评审和防护措施。

从故障建模到测试评估的完整流程

完整的故障注入测试不是"点一下按钮"，而是一条从抽象到具体、再从具体回到结论的链路。下面这张图展示了本节要建立的任务地图，后续各章节将围绕这条链路逐段展开。

这条链路中，最容易被忽视的是第①步和第⑤步。很多团队直接跳到"注入执行"，结果故障定义含糊，判据缺失，最后只能得到"好像有问题"的结论。正确的做法是：在故障建模阶段就写清楚"什么条件下、什么故障、持续多久、期望设备做什么"；在评估阶段用同一套判据去比对实际响应，形成可追溯的结论。

一个可执行的最小示例

为了把上述流程落到具体操作，下面给出一个最小可执行示例。被测对象是一台带 CAN 通信的电机控制器，测试目标是验证"当 CAN 总线连续丢失 5 帧控制报文时，控制器应在 100 ms 内进入安全停机状态并点亮故障指示灯"。

故障建模结果：故障类型为报文丢失，触发条件为总线静默，持续时间为 5 个报文周期（假设周期 10 ms，即 50 ms），影响范围为控制指令通道。场景设计参数如下表所示。

注入执行时，使用 CAN 总线注入工具在指定时刻屏蔽 0x180 报文的发送，同时用示波器或总线记录仪采集 CAN_H/CAN_L 差分信号和控制器故障引脚电平。数据采集需要保证时间戳对齐，建议以注入触发信号为 t=0 基准。评估时，从记录中读取故障引脚拉高时刻 t1 和转矩指令归零时刻 t2，若 t1−t0 ≤ 100 ms 且 t2−t0 ≤ 100 ms，则判据1和判据3通过；再目视或通过光敏传感器确认指示灯状态。

后续章节的任务地图

围绕上面这条链路，本课程后续将依次展开：故障模式与影响分析如何转化为可注入的故障模型；典型故障类型（通信故障、电源故障、传感器故障、软件故障）的注入方法与工具选型；测试用例设计与判据编写；数据采集与时间对齐；结果评估与缺陷归档；以及在 HIL 台架和真实设备上的综合演练。每一章都会给出可操作的参数、步骤和判断依据，而不是停留在概念层面。

学习本章后，你应该能够回答三个问题：我的设备要验证哪些故障场景？这些场景的触发条件、持续时间和判据是什么？注入之后我采集什么数据、用什么标准判断通过与否。把这三个问题写清楚，故障注入测试就已经成功了一半。