3. 故障模型分类：硬件故障、软件故障、时序故障、通信故障
做车载RTOS测试这么多年，我最大的体会就是：故障不会按教科书来。你设计得再完美的系统，总会在某个深夜的测试中给你来个“惊喜”。所以，搞故障注入的第一步，就是搞清楚——我们到底要模拟哪些故障？
我个人习惯把故障模型分成四大类：硬件、软件、时序、通信。这四类基本覆盖了车载嵌入式系统里99%的异常场景。下面我一个一个说。
3.1 硬件故障：最“实在”的破坏
硬件故障，说白了就是芯片、电路、传感器这些物理器件出了问题。这类故障最直接，也最好理解——东西坏了嘛。
我在项目中遇到过最典型的一次：某款ADAS摄像头在高温老化测试后，输出图像开始出现随机条纹。一开始以为是算法问题，查了三天，最后发现是电源管理芯片的LDO输出纹波超标，导致传感器供电不稳。嗯，这就是典型的硬件故障。
常见的硬件故障模型包括：
- 位翻转（Bit Flip）：内存或寄存器中的某一位突然从0变1，或从1变0。原因可能是宇宙射线、电磁干扰。你想想看，一个刹车控制系统的状态寄存器被翻转了，后果是什么？
- 信号毛刺（Glitch）：数字信号线上出现宽度极窄的脉冲。我见过最离谱的一次，一个GPIO毛刺直接触发了ECU的紧急断电逻辑。
- 电源跌落/过压：供电电压瞬间低于或高于额定范围。车载12V/24V系统里，这种故障太常见了。
- 时钟抖动/漂移：时钟信号不稳定，导致时序错乱。
- 传感器失效：输出卡在某个固定值（Stuck-at），或者输出完全超出量程。
重点提醒：硬件故障的注入，一定要考虑“故障持续时间”。是永久性的（比如芯片烧了），还是瞬态性的（比如一个毛刺）？这两种情况，RTOS的处理策略完全不同。
3.2 软件故障：最“隐蔽”的敌人
软件故障，说白了就是代码写错了。但注意，我们这里讨论的不是普通的bug，而是在特定条件下才会触发的、具有随机性或偶发性的故障。
我曾经在一个项目中，被一个“野指针”折磨了整整两周。那个指针只有在某个特定CAN报文组合到达时才会被错误赋值，然后系统就随机死机。这就是典型的软件故障——复现条件极其苛刻。
常见的软件故障模型：
- 内存越界/溢出：数组访问超出边界，或者堆栈溢出。RTOS里，任务栈溢出是头号杀手。
- 死锁/活锁：两个或多个任务互相等待对方释放资源，谁也动不了。
- 优先级反转：高优先级任务被低优先级任务阻塞，导致实时性崩溃。
- 数据竞争：多个任务同时访问共享数据，没有做同步保护。
- 异常返回：中断服务程序或系统调用返回时，上下文恢复出错。
我的经验：软件故障注入，最有效的方法是“修改关键变量的值”。比如，把一个任务的控制块中的状态字段强行改成“挂起”，看看系统会不会崩溃。这比模拟内存越界要可控得多。
3.3 时序故障：最“难缠”的对手
时序故障，是车载RTOS测试里最让我头疼的一类。为什么？因为硬件和软件故障，你至少知道“它坏了”或者“它写错了”。但时序故障，所有东西看起来都是对的，但就是跑不出正确结果。
举个例子：一个任务每10ms执行一次，负责采集轮速传感器数据。正常情况下，采集、处理、发送CAN报文，总共耗时2ms。但某天，因为另一个高优先级任务突然占用了大量CPU时间，这个轮速任务被延迟了8ms才得到执行。结果呢？轮速数据采集晚了，计算出的车速比实际慢了10km/h。这就是时序故障——功能逻辑没错，但时间不对。
常见的时序故障模型：
- 任务超时：任务执行时间超过了其截止时间（Deadline）。
- 中断延迟：从中断触发到ISR开始执行的时间过长。
- 调度抖动：任务的实际释放时间与理论释放时间之间的偏差。
- 时钟同步偏差：多核或多ECU系统中，不同时钟源之间的时间差。
- 看门狗误触发：因为任务执行时间波动，导致看门狗计数器没有被及时喂狗。
注意：时序故障的注入，不能简单地“加延时”。因为加延时本身会改变系统的调度行为。我建议用“抢占注入”的方法——在目标任务执行的关键路径上，插入一个高优先级的中断或任务，强行抢占CPU。这样更接近真实场景。
3.4 通信故障：最“复杂”的考验
车载系统里，通信无处不在。CAN、LIN、FlexRay、以太网……任何一个通信链路出问题，都可能导致整个系统瘫痪。而且，通信故障往往具有传播性——一个节点的通信故障，可能会让其他节点也陷入混乱。
我记得有一次测试，一个BMS（电池管理系统）通过CAN总线发送电池状态数据。因为CAN总线上的终端电阻虚焊，导致信号反射严重，BMS发送的数据帧CRC校验频繁失败。结果呢？整车控制器收不到有效数据，直接进入了“跛行模式”，车速被限制在20km/h。你看，一个电阻的问题，通过通信链路放大成了整车故障。
常见的通信故障模型：
- 报文丢失：发送方发了，但接收方没收到。可能是总线冲突、缓冲区溢出、或者物理层问题。
- 报文重复：同一个报文被接收了两次或多次。这在CAN总线里比较少见，但在以太网里很常见。
- 报文延迟：报文到达时间超出了预期窗口。
- 报文错误：数据内容被篡改（比如CRC错误），或者报文格式不对。
- 总线静默：某个节点完全不发送任何报文，或者总线完全瘫痪。
- 网络分区：因为交换机或网关故障，导致网络被分割成多个无法通信的孤岛。
| 故障类型 | 典型注入方法 | 影响范围 | 检测难度 |
|---|---|---|---|
| 报文丢失 | 在发送端或接收端丢弃特定ID的报文 | 局部 | 低 |
| 报文延迟 | 在通信栈中插入延时 | 局部到全局 | 中 |
| 总线静默 | 关闭节点的收发器 | 全局 | 低 |
| 数据篡改 | 修改报文payload中的关键字节 | 局部 | 高 |
| 网络分区 | 断开网关或交换机的某条链路 | 全局 | 高 |
核心观点：这四类故障不是孤立的。一个硬件故障（比如晶振损坏）可能引发时序故障（时钟不准），进而导致通信故障（CAN报文同步丢失）。所以，做故障注入测试时，我建议先从单一故障开始，逐步过渡到组合故障。别一上来就搞“混合双打”，否则你根本定位不到根因。
好了，故障模型分类就讲到这里。下一章，我会详细讲每种故障模型的具体注入方法和工具。到时候，我会拿出一些我实际用过的代码和脚本，咱们一起看看怎么“搞破坏”。