二、故障模式分析：FCC常见硬件故障与软件故障
好，咱们接着聊。上一章我讲了FCC的基本架构和容错理念，这一章咱们得动真格的了——分析故障。
做FCC这么多年，我最大的体会是：你不可能防住所有故障，但你必须知道它长什么样。说白了，故障模式分析就是给故障“画像”。画得越准，后面的容错机制就越有针对性。
我个人习惯把FCC的故障分成两大类：硬件故障和软件故障。咱们一个一个来拆。
2.1 硬件故障：那些“硬伤”
硬件故障，说白了就是物理层面的损坏或异常。你想想看，芯片在高温、振动、电磁干扰的环境下运行，不出问题才怪。FCC的硬件故障主要集中在四个核心部件：CPU、内存、I/O接口和电源。
2.1.1 CPU故障
CPU是FCC的大脑，它要是出问题，整个系统基本就瘫了。常见的CPU故障有这几类：
- 指令执行错误：CPU内部逻辑单元出错，算出来的结果不对。我在项目中遇到过，一个加法指令算出来结果差了1，查了三天才发现是ALU的某个晶体管老化了。
- 寄存器数据损坏：寄存器里的值被宇宙射线“翻转”了。嗯，这不是科幻片，在航空电子领域这叫“单粒子翻转”，很常见。
- 时钟抖动或失锁：CPU的时钟信号不稳定，导致时序错乱。我曾经见过一个案例，电源纹波太大，直接把CPU的PLL给“晃”失锁了。
- 缓存一致性错误：多核CPU的L1/L2缓存数据不一致。这个在FCC里特别要命，因为三模冗余的CPU之间需要同步数据。
避坑指南：我曾经在一个项目中，CPU的缓存一致性错误导致三个通道的计算结果各不相同，但每个通道自己检查都是“正确”的。最后花了整整两周，才定位到是缓存同步逻辑的时序余量不够。所以，CPU故障检测不能只看“有没有输出”，还要看“输出对不对”。
2.1.2 内存故障
内存故障在FCC里非常普遍。为什么？因为内存单元密度高，对辐射和电压波动特别敏感。
| 故障类型 | 表现 | 我见过的案例 |
|---|---|---|
| 单比特翻转 | 某个bit从0变1或1变0 | SRAM中存储的飞行参数被翻转，导致导航计算偏差 |
| 多比特翻转 | 相邻多个bit同时出错 | 高能粒子轰击导致连续4个bit出错，ECC都救不了 |
| 地址线故障 | 读写到了错误的地址 | 地址线虚焊，写A地址实际写到了B地址 |
| 数据线短路 | 两根数据线连在一起了 | PCB工艺问题，D0和D1短路，读出来的数据永远是0x00或0xFF |
| 存储单元老化 | 写入后保持时间变短 | Flash经过10万次擦写后，某些单元再也写不进去了 |
这里我要特别强调一下：内存故障往往是“软错误”，就是重启一下可能就好了。但FCC不能依赖重启，因为飞行器在空中不可能让你重启。所以，内存的容错机制必须做到“在线修复”。
2.1.3 I/O接口故障
I/O接口是FCC和外界通信的通道。ARINC 429、CAN总线、离散量接口、模拟量采集……这些接口一旦出问题，传感器数据进不来，执行机构的指令出不去，系统就成了“聋子”和“哑巴”。
- 电气故障：电平不匹配、信号幅度不够、共模电压超标。我记得有一次，一个离散量输入接口的滤波电容漏电，导致高电平被拉低，系统误判为“开关断开”。
- 时序故障：数据采样时刻不对，导致误码。CAN总线的位时序如果配置不对，整个网络都会乱套。
- 协议故障：数据帧格式错误、校验码错误。这个在ARINC 429里特别常见，因为它的数据格式比较古老，很容易出现标号错误或SDI字段错误。
- 物理连接故障：插头松动、焊点开裂、线缆断裂。嗯，这个最头疼，因为它是间歇性的——飞机颠簸一下就断一下，地面测试又好了。
我的经验：I/O接口故障的检测，一定要做“回环测试”。就是发出去一个数据，再读回来对比。如果发和收不一致，那接口肯定有问题。我在设计FCC时，每个I/O通道都内置了回环测试逻辑，每100ms自检一次。
2.1.4 电源故障
电源是FCC的“血液”。电源出问题，所有芯片都跟着遭殃。
- 电压跌落：瞬间电压低于芯片工作阈值。我见过一个案例，电机启动时电流冲击太大，把FCC的3.3V拉到了2.8V，FPGA直接配置丢失。
- 电压过冲：瞬间电压过高，烧毁芯片。这个不用多说，芯片冒烟就是这结果。
- 纹波过大：电源输出有交流分量，干扰芯片正常工作。ADC采集精度下降、时钟抖动增加，都是纹波惹的祸。
- 电源时序错误：多路电源的上电/掉电顺序不对。FPGA的内核电压和I/O电压如果上电顺序反了，可能会损坏IO引脚。
警告：电源故障的检测不能只靠电压监控芯片。我曾经遇到过，电压监控芯片本身先坏了，导致系统在电压已经跌落到2.0V时还报告“电源正常”。所以，电源监控电路本身也需要冗余。
2.2 软件故障：那些“软伤”
硬件故障是物理层面的，软件故障则是逻辑层面的。很多人觉得软件故障比硬件好处理，其实不然。软件故障的隐蔽性更强，复现更难，有时候比硬件故障更让人头疼。
2.2.1 死锁
死锁，说白了就是两个或多个任务互相等待对方释放资源，结果谁也动不了。
在FCC里，死锁的典型场景是这样的：
- 任务A持有资源R1，等待资源R2
- 任务B持有资源R2，等待资源R1
- 两个任务就这么僵住了，系统“假死”
为什么会这样？我分析过，根本原因有三个：
- 资源分配不当：多个任务共享了同一个互斥锁，但没有统一的加锁顺序
- 任务优先级反转：低优先级任务持有锁，高优先级任务等锁，中间优先级任务抢占了CPU，低优先级任务一直得不到执行，锁就一直释放不了
- 中断与任务的锁冲突：中断服务程序里尝试获取一个已经被任务持有的锁
避坑指南：我曾经在一个项目中，FCC的飞控任务和导航任务因为共享一个数据缓冲区而发生了死锁。飞控任务先锁了缓冲区，然后去读传感器数据；导航任务先锁了传感器数据，然后去读缓冲区。结果两个任务互相等，系统在飞行中“卡住”了3秒钟。3秒钟对于飞行控制来说，足够让飞机翻个跟头了。从那以后，我定了一个铁律：所有锁的获取顺序必须全局统一，并且禁止在中断中获取任何锁。
2.2.2 内存泄漏
内存泄漏，就是程序动态分配了内存，但用完后没有释放。一次泄漏几字节，看起来没什么。但FCC是长期运行的，飞一次可能十几个小时。泄漏累积下来，内存池就枯竭了。
我见过最典型的场景：
- 一个通信任务，每次收到消息都malloc一块缓冲区
- 处理完消息后，忘了free
- 飞行了8小时后，内存耗尽，系统崩溃
内存泄漏的检测其实不难，难的是定位。我常用的方法：
- 静态代码分析：用工具扫描代码，找出malloc和free不匹配的地方
- 动态内存监控：在运行时记录每次malloc和free的调用栈，定期检查哪些内存没有被释放
- 内存池上限检查：给每个任务分配固定大小的内存池，超过上限就报警
我的建议：在FCC这种安全关键系统中，我强烈建议禁止使用动态内存分配。所有内存都在编译时静态分配好。这样虽然浪费一点内存，但彻底杜绝了内存泄漏和内存碎片的问题。我在最近三个FCC项目中都是这么做的，效果非常好。
2.2.3 栈溢出
栈溢出，就是函数调用层次太深，或者局部变量太大，把栈空间给撑爆了。
栈溢出在FCC里特别危险，因为：
- 栈溢出会覆盖相邻的内存区域，可能是其他任务的栈，也可能是全局变量
- 被覆盖的数据可能不会立即出错，而是过一段时间才暴露出来
- 定位极其困难，因为出错的位置和栈溢出的位置往往不在同一个地方
我遇到过这样一个案例：一个中断服务程序里调用了printf函数，而printf内部又调用了其他函数，导致栈空间不够用。结果栈溢出的数据覆盖了任务控制块，导致任务调度器崩溃。整个系统在没有任何预警的情况下直接“死机”。
怎么防？我的做法是：
- 栈空间留足余量：实际需要的栈空间乘以2，甚至乘以3
- 栈边界填充“哨兵”值：在栈的底部和顶部填充0xDEADBEEF之类的特殊值，定期检查这些值有没有被覆盖
- 使用硬件栈保护：有些CPU有MPU（内存保护单元），可以设置栈区域的访问权限，一旦越界就触发异常
- 递归函数一律不用：在FCC的代码里，我禁止使用递归。递归的深度不可控，太容易栈溢出了
警告：栈溢出检测不能只靠软件。我曾经在一个项目中，软件检测栈溢出的代码本身就在栈上运行，结果栈溢出了，检测代码也跟着崩溃了。所以，栈溢出检测最好用硬件机制（MPU或看门狗）来实现。
2.3 小结
好了，这一章的内容就这么多。咱们把FCC常见的故障都过了一遍：
- 硬件故障：CPU、内存、I/O、电源
- 软件故障：死锁、内存泄漏、栈溢出
你可能会问：知道了这些故障有什么用？嗯，用处大了去了。下一章，咱们就要基于这些故障模式，设计具体的检测和容错机制。你想想看，如果你连敌人长什么样都不知道，你怎么设计武器？
所以，这一章的内容是基础，是后面所有容错设计的“靶子”。把故障模式分析清楚了，后面的设计才能有的放矢。
好，下一章见。