3、故障模式与影响分析（FMEA）
各位同事，今天我们来聊聊FMEA。说实话，这玩意儿在ATO系统里，就像医生手里的听诊器——你得知道哪里会出问题，才能提前下药方。
我个人习惯把FMEA叫做“故障的天气预报”。你想想看，如果能在故障发生前就预判到它，那咱们的自动驾驶系统得多安全？
3.1 FMEA方法论：从“事后诸葛亮”到“事前诸葛亮”
FMEA，全称是Failure Mode and Effects Analysis。说白了，就是系统性地问自己三个问题：
- 哪里会坏？（故障模式）
- 坏了会怎样？（影响分析）
- 怎么提前发现？（探测手段）
我在项目中遇到过不少团队，上来就写代码，出了问题再回头补FMEA。嗯，这其实是个坑。真正的做法应该是：设计阶段就把FMEA做透。
核心原则：FMEA不是一次性的文档，而是贯穿整个开发周期的“活地图”。每次迭代、每次变更，都要重新审视它。
具体怎么做？我一般分五步走：
- 定义系统边界——搞清楚你要分析的是哪个子系统。比如ATO的“速度控制模块”还是“车门控制模块”？
- 列出所有可能的故障模式——别怕多，越全越好。我记得有一次，我们漏掉了一个“通信超时”的故障模式，结果现场测试时差点出事故。
- 分析每个故障的影响——分局部影响和全局影响。比如“速度传感器失效”，局部影响是测速不准，全局影响可能是列车超速。
- 评估现有控制措施——看看你现有的设计能不能兜住这个故障。
- 计算RPN并排序——RPN就是风险优先级数，后面会细讲。
3.2 在ATO系统中的应用：实战案例
咱们拿ATO系统里最常见的“速度传感器故障”来举例。你想想看，如果列车不知道自己跑多快，那自动驾驶就是个笑话。
我曾经处理过一个真实案例：某线路的ATO在进站时突然急刹车，乘客全往前倒。排查下来，就是速度传感器间歇性失效，导致系统误判为超速。
下面是我当时做的FMEA表格（简化版）：
| 故障模式 | 故障原因 | 局部影响 | 全局影响 | 现有控制措施 |
|---|---|---|---|---|
| 速度传感器输出异常 | 传感器老化、线路接触不良 | 测速值跳变 | 列车误判超速，触发紧急制动 | 双传感器冗余、阈值滤波 |
| 通信链路中断 | 网线松动、交换机故障 | 数据包丢失 | ATO降级为人工驾驶 | 心跳检测、冗余网络 |
| 制动指令无响应 | 制动控制器死机 | 制动不执行 | 列车无法停车，可能追尾 | 看门狗定时器、硬线备份 |
我的小技巧：做FMEA时，别只盯着“硬件故障”。软件逻辑错误、时序问题、甚至人为操作失误，都要列进去。我曾经就吃过“软件版本不匹配”的亏，那叫一个惨。
3.3 严重度/频度/探测度评级：RPN是怎么算出来的？
好，接下来是FMEA的核心——三个维度的评级。我习惯叫它“三度空间”。
3.3.1 严重度（Severity）
严重度，就是故障发生后，后果有多严重。我一般用1到10分来打分：
- 1-3分：轻微影响。比如某个指示灯不亮，但不影响驾驶。
- 4-6分：中等影响。比如需要人工干预，但还能安全运行。
- 7-9分：严重影响。比如列车降级运行，或者需要紧急制动。
- 10分：灾难性影响。比如列车失控、碰撞、人员伤亡。
嗯，这里要注意：在ATO系统里，凡是涉及“安全功能丧失”的，严重度至少给8分以上。别手软。
3.3.2 频度（Occurrence）
频度，就是故障发生的概率。同样1到10分：
- 1分：几乎不可能发生。比如每100年一次。
- 4-6分：偶尔发生。比如每月一次。
- 10分：几乎必然发生。比如每天一次。
我个人习惯参考历史数据。如果某个故障在之前的项目中出现过，频度至少给5分。别太乐观，现实往往比想象中残酷。
3.3.3 探测度（Detection）
探测度，就是故障发生前，你能不能发现它。注意，分数越高代表越难发现：
- 1分：很容易发现。比如有明确的报警灯。
- 5分：需要一定手段才能发现。比如通过数据分析才能察觉。
- 10分：几乎无法发现。直到故障发生才知道。
避坑指南：我曾经犯过一个错误——把探测度打得太低。当时觉得“这个故障肯定能被检测到”，结果现场测试时才发现，检测逻辑有个边界条件没覆盖。从那以后，我给自己定了个规矩：探测度至少给3分起步，除非你有100%的把握。
3.3.4 RPN计算与优先级
RPN = 严重度 × 频度 × 探测度。就这么简单。
举个例子：
- 速度传感器故障：严重度8，频度4，探测度3 → RPN = 8×4×3 = 96
- 通信链路中断：严重度7，频度5，探测度4 → RPN = 7×5×4 = 140
- 制动指令无响应：严重度10，频度2，探测度6 → RPN = 10×2×6 = 120
你看，虽然“制动指令无响应”的严重度最高，但因为频度低，RPN反而比“通信链路中断”低。这就是FMEA的价值——帮你找到真正的“高优先级”问题。
我的经验：RPN超过100的，必须立即整改。超过50的，要制定改进计划。低于50的，可以持续监控。但别死磕数字，有时候严重度10分的故障，即使RPN只有30，也得优先处理——因为人命关天。
3.4 实战中的FMEA迭代
FMEA不是做完就完事的。我建议每个版本迭代时，都重新过一遍FMEA。为什么？因为系统在变，故障模式也在变。
我记得有一次，我们升级了ATO的通信协议，结果引入了一个新的故障模式——数据包乱序。这个在旧版本里根本不存在。幸好FMEA迭代时发现了，不然上线后肯定出乱子。
所以，我的建议是：
- 设计阶段：做初步FMEA，识别高风险项。
- 开发阶段：根据FMEA结果，设计针对性的检测和恢复机制。
- 测试阶段：用FMEA指导测试用例设计，重点覆盖高风险故障。
- 运维阶段：根据现场数据，更新FMEA的频度和探测度评级。
说白了，FMEA就是个“活文档”。你越用它，它越准。
最后分享一个心得：做FMEA时，一定要拉上不同角色的人一起讨论。硬件工程师、软件工程师、测试工程师、甚至运维人员，每个人看到的故障模式都不一样。我曾经在一次FMEA评审会上，被运维小哥一句话点醒——他说“你们设计的那个自检逻辑，在雨天经常误报”。你看，这就是实战经验的价值。