2. 故障诊断基础理论：FMEA、FTA与系统可靠性模型

各位同学，咱们今天聊点硬核的。故障诊断不是靠猜，也不是靠拍脑袋。它背后有一套成熟的理论体系。我个人习惯，在动手排查任何系统之前，先问自己三个问题：“哪里会坏？”、“坏了会怎样？”、“怎么找到它？”。今天讲的这三个工具，就是回答这些问题的钥匙。

2.1 故障模式与影响分析（FMEA）

FMEA，说白了就是“事前诸葛亮”。在系统还没出问题的时候，我们就坐下来，把每个零件、每个模块可能发生的故障，全都列出来。然后评估它有多严重。

核心步骤就三步：

1. 列出故障模式：比如传感器短路、通信丢包、电源纹波过大。
2. 分析影响：这个故障会导致什么后果？是功能降级，还是系统停机？
3. 评估风险：用严重度（S）、发生度（O）、检测度（D）三个维度打分。乘起来就是RPN（风险优先级数）。

我在项目中遇到过一件事。一个多模态融合系统，摄像头和激光雷达的数据总是对不上。我们查了三天，最后用FMEA一梳理，发现是时间戳同步模块的“时钟漂移”模式被漏掉了。嗯，这个模式的发生度是7，严重度是9，RPN高达63。补上这个分析后，问题根源一目了然。

2.2 故障树分析（FTA）

FMEA是自下而上找影响，FTA是自上而下找原因。它像一棵倒着长的树。树根是“系统故障”，树枝是“中间事件”，树叶是“基本故障”。

举个例子：“自动驾驶车辆无法识别障碍物”。这是顶事件。

• 往下分，可能是“摄像头故障”或“激光雷达故障”或“算法失效”。
• 再往下，“摄像头故障”可能是“镜头脏污”、“硬件损坏”、“供电异常”。
• 一直分到不能再分为止。

FTA用逻辑门连接事件。最常见的是“与门”和“或门”。

• 与门：所有下层事件都发生，上层才发生。比如“双电源同时失效”，才导致系统掉电。
• 或门：任何一个下层事件发生，上层就发生。比如“摄像头坏”或“雷达坏”，都会导致感知失效。

FTA的好处是，它能帮你找到系统的薄弱环节。如果一棵故障树里，某个基本事件出现在很多条路径上，那它就是“单点故障”。这种地方，必须加冗余。

2.3 系统可靠性模型

可靠性模型，说白了就是算概率。一个系统到底有多可靠？不是拍胸脯说“很可靠”，而是用数字说话。

最常用的模型有三种：

模型	结构	公式	适用场景
串联模型	所有部件必须都正常	R = R1 × R2 × ... × Rn	单链路系统，如单一传感器
并联模型	只要一个部件正常就行	R = 1 - (1-R1)×(1-R2)×...	冗余系统，如双电源
k/n 模型	n个部件中至少k个正常	R = Σ(C(n,i)×R^i×(1-R)^(n-i))	表决系统，如三取二

你想想看，一个多模态系统，摄像头、雷达、IMU三个传感器串联。每个可靠性都是0.99。那整个系统的可靠性是多少？

R = 0.99 × 0.99 × 0.99 = 0.9703

嗯，只有97%。也就是说，每100次运行，就有3次会出问题。这显然不够。所以实际工程中，我们会在关键路径上加并联冗余。

2.4 三者如何配合使用？

这三个工具不是孤立的。我个人习惯的流程是这样的：

1. 先用FMEA，把系统里所有可能的故障模式列出来，找出高风险项。
2. 再用FTA，针对高风险项，画故障树，找到根本原因。
3. 最后用可靠性模型，算一下改进后的系统，可靠性到底提升了多少。

举个例子。我在做车载多模态系统时，发现“感知失效”的RPN很高。于是画了FTA，发现“摄像头被遮挡”是主要根因。然后我加了超声波雷达做冗余，用并联模型一算，可靠性从0.97提升到了0.9991。嗯，这个结果，客户很满意。