2. 车载软件基础
做故障注入这么多年，我最大的体会就是：你不可能测出你没想到的故障。所以，在动手注入之前，先把故障模型搞清楚，比什么都重要。说白了，这就是一本“故障字典”。你翻过字典，才知道眼前这个系统到底可能得什么病。
这一章，咱们就把硬件和软件里最常见的几类故障模型掰开揉碎。我挑的都是实际项目中反复出现的“老面孔”。
硬件故障模型
硬件故障，听着很硬核，其实很多都源于物理世界的“不完美”。宇宙射线、电磁干扰、制造缺陷……这些都能让芯片里的晶体管“抽风”。
1. 单粒子翻转 (SEU)
单粒子翻转，英文叫 Single Event Upset。这名字听着挺学术，其实说白了就是：一个高能粒子打中了芯片里的存储单元，把 0 变成了 1，或者把 1 变成了 0。
为什么会这样？芯片里的 SRAM 或寄存器，是靠微小的电荷来存储数据的。一个高能粒子（比如宇宙射线）打进来，瞬间产生大量电子-空穴对，就能把存储节点的电平“冲”翻。
关键特征：
- 瞬时性：故障只发生一瞬间，不会永久损坏器件。
- 随机性：发生在哪个比特、哪个时刻，完全随机。
- 非破坏性：重新写入正确值后，器件可以恢复正常工作。
我在项目中遇到过最典型的例子，是卫星上的通信载荷。在实验室里跑得好好的，一上天就时不时丢包。后来定位到是星载计算机的寄存器被高能粒子打翻了。嗯，这就是典型的 SEU。
我的经验：SEU 在航空、航天、高海拔数据中心里是家常便饭。地面上的服务器虽然受大气层保护，但随着芯片制程越来越小（7nm、5nm），SEU 的发生率也在悄悄上升。别以为只有上天才会遇到。
2. 位翻转 (Bit Flip)
位翻转，其实是 SEU 的“症状”。一个比特从 0 翻成 1，或者从 1 翻成 0，这就是位翻转。但位翻转不一定是粒子打的，也可能是电源波动、时钟抖动、甚至信号串扰引起的。
你想想看，一个 32 位的寄存器，如果最高位（符号位）被翻转了，正数直接变负数。如果是地址总线上的位翻转，程序可能直接跳到火星上去了——段错误、非法指令，什么妖魔鬼怪都能出来。
| 翻转位置 | 可能后果 | 严重程度 |
|---|---|---|
| 数据寄存器 | 计算结果错误 | 中 |
| 地址寄存器 | 非法内存访问、崩溃 | 高 |
| 控制寄存器 | 状态机跳转错误、死锁 | 极高 |
| 指令寄存器 | 执行错误指令、程序跑飞 | 极高 |
避坑指南：我曾经调试过一个网络设备，偶尔会发出错误的 MAC 地址。查了三天，最后发现是 DMA 描述符里的一个控制位被翻转了。从那以后，我对所有关键控制结构都强制加了 ECC 校验。别信“概率很低”这种话，碰上一次就够你喝一壶。
3. 卡死故障 (Stuck-at Fault)
卡死故障，是硬件故障模型里最“老实”的一种。一个信号线，要么卡死在逻辑 0（Stuck-at-0），要么卡死在逻辑 1（Stuck-at-1）。它不会变，就这么一直“死”着。
这种故障通常是由物理缺陷引起的：比如焊点虚焊、金属线断裂、晶体管击穿。在芯片制造测试中，卡死故障模型是最经典的测试向量生成依据。
我个人的习惯是，在做故障注入时，卡死故障是最容易模拟的——直接把某个信号强制拉高或拉低就行。但它的影响范围往往很大，因为一个卡死的控制信号可能让整个模块瘫痪。
// 模拟卡死故障的伪代码示例
// 假设我们有一个控制信号 enable
// 正常逻辑
if (enable) {
process_data();
}
// 注入 Stuck-at-0 故障
enable = 0; // 强制拉低
// 此时 process_data() 永远不会被执行软件故障模型
软件故障，说白了就是代码里的“坑”。硬件故障是物理世界的意外，软件故障则是逻辑世界的疏忽。这两者，一个靠天，一个靠人。
1. 内存泄漏 (Memory Leak)
内存泄漏，应该是每个程序员都遇到过的噩梦。你申请了一块内存，用完之后忘了释放。一次两次没事，但架不住程序一直跑。内存越吃越多，最后系统扛不住了——OOM（Out Of Memory）杀手登场，把你的进程直接毙了。
为什么会这样？说白了就是资源管理不严谨。C/C++ 里 malloc 了没有 free，Java 里对象引用没断干净导致 GC 无法回收，甚至 Python 里循环引用导致引用计数清不掉。
内存泄漏的典型症状：
- 进程的 RSS（常驻内存）持续增长，从不下降。
- 系统可用内存逐渐减少，Swap 使用量增加。
- 最终触发 OOM Killer，进程被强制终止。
我记得有一次，一个后台服务每处理 1000 个请求就泄漏 4KB。看起来不多，对吧？但一天处理 1000 万请求，就是 40MB。跑上一个月，1.2GB 就没了。服务器 8GB 内存，三个月后必挂。
我的建议：对于长期运行的服务，一定要做内存泄漏的故障注入测试。写一个脚本，反复调用你的核心接口，同时监控内存使用量。如果 RSS 曲线是向上走的，哪怕斜率再小，也说明有问题。
2. 空指针 (Null Pointer)
空指针，可能是软件世界里最“著名”的故障了。你声明了一个指针或引用，没有给它赋值，或者把它赋成了 null，然后你直接用它去访问成员或调用方法——砰！NullPointerException 或者段错误。
你想想看，这其实是一个契约违背的问题。函数说“你给我一个对象”，你给了个 null。函数没检查，直接用了。这就是信任的代价。
// 空指针故障的典型场景
void process_user(User* user) {
// 没有检查 user 是否为 NULL
printf("User name: %s\n", user->name); // 如果 user 是 NULL，这里就崩了
}
// 正确的做法
void process_user(User* user) {
if (user == NULL) {
// 处理错误，或者返回
return;
}
printf("User name: %s\n", user->name);
}避坑指南：我曾经接手过一个遗留系统，里面到处都是空指针崩溃。后来我强制团队执行一条铁律：所有外部输入的指针，必须判空。内部传递的指针，如果约定不为空，就用断言检查。半年后，空指针相关的崩溃减少了 90%。
3. 竞态条件 (Race Condition)
竞态条件，是并发编程里最难缠的故障。两个或多个线程同时访问共享资源，执行顺序不确定，导致结果依赖于“谁先跑完”。
为什么会这样？因为现代操作系统是抢占式调度的。线程 A 读到某个变量的值是 1，正准备加 1，结果时间片到了，被挂起。线程 B 抢到 CPU，也读到这个变量的值是 1，也加 1，写回 2。然后线程 A 恢复，它手里还攥着那个“1”，加 1 写回 2。你看，两个线程各加一次，结果应该是 3，实际却是 2。这就是经典的“丢失更新”。
| 竞态类型 | 典型场景 | 检测难度 |
|---|---|---|
| 读-改-写 | 计数器、状态标志 | 中 |
| 检查-然后-执行 | 文件存在性检查、资源分配 | 高 |
| 信号量死锁 | 多个锁的获取顺序不一致 | 极高 |
我个人习惯，在调试竞态条件时，最有效的工具就是故障注入。在关键代码路径上插入随机的 sleep，人为制造线程切换的“坏运气”。如果这样跑都能稳定通过，那竞态条件基本被消灭了。
知识结构总览
下面这张图，把本章的故障模型体系串起来了。你可以把它当作一张“故障地图”，以后遇到问题，先对号入座。
这张图把硬件和软件两大类故障模型分得清清楚楚。左边是硬件的“物理三剑客”，右边是软件的“逻辑三巨头”。每一类都有自己独特的脾气和应对方法。