2、故障诊断基础：故障树分析(FTA)、失效模式与影响分析(FMEA)、故障诊断流程

各位工程师，大家好。欢迎来到第二章。

上一章我们聊了定位模块的整体架构和常见故障类型。这一章，咱们得把诊断这件事本身给「方法论」了。说白了，就是给你一套趁手的工具，遇到问题别瞎猜，按套路来。

我个人习惯，拿到一个故障报告，不会急着拆机器。先问自己三个问题：「可能是什么？」「最可能是什么？」「怎么验证？」。而FTA和FMEA，就是回答前两个问题的利器。

2.1 故障树分析（FTA）—— 从结果倒推原因

FTA，全称 Fault Tree Analysis。这玩意儿是个「倒着推」的逻辑工具。我们先把最不想看到的结果——比如「无人机悬停漂移超过5米」——放在树顶，然后一层层往下拆，看看到底是哪些底层原因组合起来，导致了顶层故障。

它用的是布尔逻辑，也就是「与门」和「或门」。

  • 或门（OR Gate）：底下任何一个原因发生，顶上事件就发生。比如「天线损坏」或「射频芯片烧了」，都会导致「信号丢失」。
  • 与门（AND Gate）：底下所有原因同时发生，顶上事件才发生。比如「GPS信号弱」且「视觉里程计失效」，才导致「定位丢失」。这种情况相对少见，但一旦出现就是复合故障。

核心思路：FTA 帮你把模糊的「飞机坏了」变成一张清晰的逻辑图。你顺着树枝往下摸，总能找到那片「病叶子」。

我在项目中遇到过一件事。某次试飞，无人机在切换定位模式时突然往右偏了3米。当时大家第一反应是「磁罗盘受干扰」。但我用FTA一画，发现「磁罗盘故障」只是其中一个分支。顺着「定位跳变」这个顶事件往下查，最终发现是飞控的EKF（扩展卡尔曼滤波器）协方差矩阵初始化参数写错了。你看，不画树，你可能就换罗盘去了，白费功夫。

下面这张图，是我常用的一个简化版FTA模型，针对「定位精度超差」这个典型故障：

定位精度超差故障树分析（FTA） 定位精度超差 ≥1 传感器数据异常 算法/参数错误 ≥1 GPS 星数不足 IMU 零偏过大 磁罗盘受扰 ≥1 EKF 参数错误 融合权重异常 说明：顶层为顶事件，中间层为中间事件，底层为底事件。 「≥1」表示或门，任一底事件发生即可导致上层事件发生。

小技巧：画FTA时，尽量把底事件拆到「可测量」或「可替换」的程度。比如「IMU零偏过大」就是可测量的，而「传感器坏了」太笼统，不好操作。

2.2 失效模式与影响分析（FMEA）—— 提前排雷

FTA是事后诸葛亮，那FMEA就是事前预防针。FMEA的全称是 Failure Mode and Effects Analysis。它要求我们在设计阶段或量产前，就把每个零件、每个模块「可能怎么坏」列出来，然后评估它的严重程度、发生概率和可检测性。

你想想看，如果等到飞机飞丢了再去找原因，代价太大了。FMEA就是逼着你在办公室里把雷先排一遍。

FMEA的核心是三个指标：

  • S（Severity，严重度）：这个故障发生了，后果有多严重？炸机？偏航？还是只是日志里多一条警告？
  • O（Occurrence，发生度）：这个故障发生的概率有多大？是每飞必现，还是十万公里一次？
  • D（Detection，检测度）：在故障发生前，我们有没有办法发现它？比如通过自检、通过冗余比对？

然后计算一个 RPN（Risk Priority Number，风险优先级数） = S × O × D。RPN越高的项目，越需要优先处理。

我曾经在一个项目中，FMEA表格里「GPS天线脱落」这一项的RPN高达240（S=8, O=6, D=5）。后来我们加了一个天线在位检测电路，D降到了2，RPN直接降到96。这就是FMEA的价值——用数据驱动改进。

下面是一个针对定位模块的FMEA示例片段：

功能 失效模式 失效影响 S O D RPN 改进措施
GPS定位 天线脱落 定位丢失，进入悬停或返航 8 6 5 240 增加天线在位检测电路
视觉定位 镜头污损 特征点丢失，定位漂移 6 4 3 72 增加镜头清洁提醒机制
IMU 温度漂移超限 姿态解算偏差，影响定位融合 7 3 4 84 增加温度补偿算法

注意：RPN只是一个参考值，不是绝对真理。有时候S=10（炸机）的项目，即使O和D都很低，也必须处理。别被数字绑架了，要结合工程判断。

2.3 故障诊断流程 —— 从理论到实战

有了FTA和FMEA这两个工具，我们还需要一个标准流程把它们串起来。不然工具再好，用的时候手忙脚乱也不行。

我个人习惯的故障诊断流程，分五步走：

  1. 现象确认与信息收集：别急着下结论。先问清楚：什么时间、什么地点、什么飞行模式、飞了多久、日志有没有异常？我见过太多人，一听「漂移」就说是GPS问题，结果一看日志，是视觉里程计被夕阳晃了。
  2. 建立故障假设（用FTA）：根据现象，画出故障树。把所有可能的原因列出来，别漏。这一步不求精确，求全面。
  3. 优先级排序（用FMEA思维）：结合历史数据和经验，给每个假设排个序。哪个最可能？哪个最容易验证？先查哪个？
  4. 验证与隔离：通过日志分析、现场复现、替换测试等方法，逐一排除假设。记住，一次只改变一个变量。同时换三个零件，你永远不知道是哪个修好的。
  5. 根因确认与修复：找到根因后，不仅要修好，还要问一句「为什么这个故障没有被FMEA提前发现？」。把经验反馈回设计流程，这才是闭环。

嗯，这里要注意。很多工程师在第二步「建立假设」时，容易陷入思维定势。比如一看到定位不准，就只往GPS上想。其实你想想看，飞控的CPU负载过高导致EKF计算延迟，也可能造成定位输出滞后。所以，FTA的树枝一定要画全。

下面这张流程图，把整个诊断过程串起来了：

故障诊断标准流程图 1. 现象确认与信息收集 2. 建立故障假设（FTA） 3. 优先级排序（FMEA） 4. 验证与隔离 5. 根因确认与修复 反馈至FMEA与设计

避坑指南：我曾经在第四步「验证与隔离」上栽过跟头。当时为了赶时间，同时换了GPS模块和飞控板，结果问题消失了，但根本不知道是哪个零件导致的。后来同样的故障在另一架飞机上复现，又得从头查。记住，一次只换一个，这是铁律。

好了，这一章的内容就到这里。FTA和FMEA是两把「手术刀」，一个用来解剖已发生的故障，一个用来预防未发生的故障。而标准流程，就是你的「手术规范」。把这套东西练熟了，遇到定位模块的疑难杂症，你心里就有底了。

← 上一章 📖 返回目录 下一章 →