2. 故障模式与影响分析（FMEA）：硬件故障分类与故障树分析基础
各位同学，咱们今天聊点实在的。做飞控系统这么多年，我最大的体会就是：故障不是会不会发生的问题，而是什么时候发生的问题。你想想看，一架无人机在天上飞，电机在转，传感器在采集数据，芯片在高速运算——这么多环节，任何一个出岔子，后果都可能很严重。
所以，我们得学会一件事：提前把可能出问题的地方找出来，分析它会造成什么影响，然后想办法应对。这就是FMEA的核心思想。说白了，就是给系统做一次全面的“体检”和“风险评估”。
2.1 硬件故障的三种“脾气”
我个人习惯把硬件故障分成三类：永久故障、间歇故障和瞬态故障。这三兄弟脾气完全不同，处理方式也不一样。
| 故障类型 | 特点 | 典型例子 | 检测难度 |
|---|---|---|---|
| 永久故障 | 坏了就是坏了，不会自己恢复 | 芯片烧毁、线路断路、焊点脱落 | 低（一测就知道） |
| 间歇故障 | 时好时坏，看心情 | 接触不良、虚焊、热胀冷缩导致的临时断路 | 高（最难抓） |
| 瞬态故障 | 一闪而过，事后无痕 | 电磁干扰、电源毛刺、宇宙射线导致的位翻转 | 中（需要特殊手段） |
2.1.1 永久故障——最老实也最致命
永久故障，就是物理上彻底坏了。我在项目中遇到过最典型的例子：某次试飞前自检，IMU（惯性测量单元）死活报错。拆下来一量，供电引脚对地短路了——芯片内部已经烧穿。这种故障最“老实”，因为它不会跟你捉迷藏。你只要做一次完整的自检，基本都能发现。
但老实归老实，后果往往很严重。想想看，如果飞行中电机驱动MOS管击穿短路，那结果就是——电机直接抱死，飞机秒变自由落体。
2.1.2 间歇故障——最让人头疼的“幽灵”
间歇故障，我愿称之为“飞控工程师的噩梦”。它时有时无，你拿万用表去量的时候它好好的，一装回去它又犯病。为什么会这样？说白了，往往是物理接触处于临界状态。
我记得有一次，一架无人机在飞行中偶尔出现GPS信号丢失，但每次落地后测试都正常。折腾了两周，最后发现是GPS天线接口的SMA头内部有一根针脚虚焊了——飞机振动大时断开，振动小又接上。这种故障最难排查，因为它不遵循“复现-定位”的常规逻辑。
2.1.3 瞬态故障——看不见的“刺客”
瞬态故障最特殊。它发生后，硬件本身没有任何物理损伤，但系统的状态可能已经被改变了。最典型的例子就是单粒子翻转（SEU）——高能粒子穿过芯片，把存储器里的一个bit从1变成了0。
你可能会问：“这概率很低吧？” 嗯，在低空飞行的消费级无人机上确实不高。但如果你做的是高空长航时无人机，或者航天级的飞控，这个问题就必须认真对待。我在参与某型高空无人机项目时，就专门为SRAM加了ECC（纠错码）保护，就是为了防这个。
2.2 故障树分析（FTA）——从结果倒推原因
聊完故障分类，咱们来说说怎么系统性地分析故障。我个人最喜欢用的工具就是故障树分析（FTA）。它和FMEA是互补的：FMEA是从下往上（原因→影响），FTA是从上往下（顶事件→底事件）。
说白了，FTA就是问一个问题：“这个灾难性的后果，是怎么一步步发生的？”
2.2.1 故障树的基本符号
在画故障树之前，先认识几个基本符号。这些符号就像乐高积木，搭起来就能分析复杂的故障逻辑。
| 符号 | 名称 | 含义 |
|---|---|---|
| 矩形 | 顶事件/中间事件 | 需要进一步分析的事件 |
| 圆形 | 底事件 | 最基本的故障原因，不再分解 |
| 菱形 | 未展开事件 | 暂时不深入分析的事件 |
| 与门 | AND | 所有输入同时发生，输出才发生 |
| 或门 | OR | 任一输入发生，输出就发生 |
2.2.2 一个实战案例：飞控系统“失控”故障树
咱们来画一个实际的故障树。假设顶事件是：“飞行中飞控系统完全失控”。
这个顶事件怎么发生的？我把它分解成三个子事件（或门关系，任何一个成立就完蛋）：
- 主控芯片失效（永久故障：芯片烧毁）
- 传感器数据全部无效（比如IMU和GPS同时故障）
- 执行机构完全卡死（比如所有舵机或电机驱动同时失效）
咱们再往下分解“传感器数据全部无效”这个分支。它需要IMU和GPS同时失效（与门关系）。而IMU失效又可以分为：IMU_A失效 AND IMU_B失效（如果是双余度设计）。
你看，这样一层层分解下去，最后就能找到所有最根本的故障原因——比如“电源模块输出过压导致IMU_A烧毁”、“GPS天线被遮挡”等等。
2.2.3 用SVG画一个简化的故障树
下面是我用SVG画的一个简化版故障树，展示了“飞控系统失控”的顶层逻辑。你仔细看看这个结构，就能理解FTA的层次感。
2.3 FMEA与FTA的配合使用
在实际工程中，我从来不会只用一种方法。我的习惯是：先用FMEA做全面的“地毯式排查”，再用FTA针对关键风险做“深度挖掘”。
举个例子：FMEA可能会告诉你“IMU通信总线可能因为电磁干扰而出现数据错误”。但FTA会进一步告诉你——这个错误在什么条件下会导致系统失控？需要同时发生哪些其他故障？
好了，关于故障分类和故障树分析，我就讲这么多。这些东西看起来是理论，但每一条背后都有血的教训。我曾经因为忽略了一个间歇故障的排查，导致整个试飞周期推迟了一个月。从那以后，我对FMEA和FTA的态度就是——宁可多花时间在图纸上，也不要多花时间在返修上。
公众号:蓝海资料掘金营，微信deep3321