系统FMEA案例实战解析：那些教科书上不会告诉你的细节

去年年底参加一个汽车行业的技术交流会，席间聊起FMEA这个话题，结果发现一个有趣的现象：几乎每个工程师都能把FMEA的七步法倒背如流，但真正做项目的时候，还是会踩进同样的坑里。这让我意识到，理论学习和实战之间隔着一条不小的鸿沟。今天这篇文章，我想用一种比较接地气的方式，结合几个真实案例，跟大家聊聊系统FMEA到底应该怎么做才能真正发挥作用。

在开始之前，我想先说个事儿。我刚入行那会儿，对FMEA的理解就是"填表格"，领导说这个功能要做FMEA，我就找模板、填参数、列失效模式，一套流程走下来觉得自己可专业了。直到有一天，产品出了问题，我们复盘的时候发现，那个失效模式其实早就写在FMEA里了，但就是没人重视它。那一刻我才明白，FMEA不是填表格游戏，而是需要真正思考和团队协作的工程技术。

系统FMEA到底是个什么东西？

可能有些朋友对FMEA的概念还不太清楚，我先用大白话解释一下。FMEA全称叫"失效模式与影响分析"，听起来挺高大上，其实核心思想特别简单：我们在设计或者制造一个东西之前，先想想它可能会坏在哪里，坏了之后会有什么后果，然后想办法在出问题之前把这些隐患给消除掉。

系统FMEA跟普通的FMEA有什么不一样呢？如果把普通FMEA比作检查单个零件有没有问题，那系统FMEA就是站在整个系统的角度上看，看看各个零件之间配合起来会不会出什么问题。这就好比检查一辆汽车，光看发动机、变速箱、刹车系统各自有没有毛病还不够，还得想想它们组合在一起的时候会不会有什么奇怪的反应。

举个生活中的例子可能更容易理解。我家有个智能家居系统，有一天我设置了一个自动化场景：晚上10点后如果有人 motion detecting，就自动打开走廊灯并发送警报通知。结果有天晚上我爸妈过来住，他们习惯早睡早起，早上5点起来去厨房喝水，结果整个房子警报大作，把邻居都吵醒了。这就是典型的系统层面的问题——各个功能单独看都没问题，但组合在一起就出乱子了。系统FMEA要解决的就是这类问题。

薄云在系统FMEA实践中的一些经验总结

在我们薄云的研发团队里，系统FMEA已经成为了产品开发流程中不可或缺的环节。这倒不是领导要求的，而是大家慢慢发现，做了系统FMEA之后，后期返工的情况确实少了很多。不过这个过程也不是一帆风顺的，我们也是踩了不少坑才慢慢摸索出一些心得。

最开始的几年，我们做系统FMEA就是走个形式。几个工程师关在会议室里，对着模板一顿填写，然后归档完事。后来产品出了问题，我们才意识到这种做法根本没用。再后来，我们改变了策略，把FMEA当成一个真正的讨论会，而不是填表任务。这个转变看起来简单，但效果却是立竿见影的。

现在我们做系统FMEA，通常会邀请不同背景的工程师一起参与。机械的、电气的、软件的、测试的，大家坐在一起头脑风暴。每个功能模块可能会有什么问题，不同模块之间会不会有冲突，各种极端情况会引发什么后果，这些问题在讨论中往往能发现很多单兵作战时想不到的东西。

我们的FMEA团队一般这样组建

在薄云，我们组建FMEA团队有几个基本原则。首先是跨职能，绝对不能让一个专业的人独自做系统FMEA，因为一个人的视野终究有限。我们曾经让一个软件工程师单独负责一个子系统的FMEA，结果他漏掉了机械结构方面的问题，因为在他的认知里，那些东西是"硬件的事"。后来我们强制要求必须要有机械工程师参与同样的模块，果然发现了软件视角看不到的风险点。

其次是老中青结合。老工程师经验丰富，知道哪些地方容易出问题；年轻工程师思维活跃，常常能提出一些大胆的假设。如果全是老工程师，可能会有思维定式；如果全是新人，又可能考虑不周全。我们有个经典的案例，就是一个刚毕业两年的工程师提出了一个"荒谬"的想法，当时被好几个老工程师嘲笑，结果后来真的在测试中出现了这个问题。从那以后，大家对年轻同事的意见都格外重视了。

还有一点也很重要，就是要有专门的人负责"唱反调"。这个人不是要否定大家的观点，而是要站在挑刺的角度不断追问：这个失效模式真的会发生吗？有没有我们没想到的触发条件？如果这个防护措施失效了怎么办？起初大家觉得这个人很讨厌，但慢慢地，所有人都意识到了这种"讨厌"的价值。

一个完整的系统FMEA案例解析

说了这么多理论，可能大家还是有点懵。接下来我给大家分享一个具体的案例，这个案例来自于我们薄云某款工业控制产品的开发过程。为了方便说明，我对具体参数做了一些简化，但问题本身是真实存在的。

案例背景

这个产品是一个用于自动化产线的控制系统，核心功能是接收传感器信号、处理数据、控制执行机构。整个系统由电源模块、主控板、通讯模块、IO模块和执行机构驱动几个部分组成。产品开发到一定阶段时，我们决定对整个系统做一次系统FMEA。

在开始之前，我们先花了半天时间把系统的边界和接口定义清楚。这部分工作看起来简单，但其实非常重要。如果我们不清楚系统跟外部怎么交互，有哪些输入输出，潜在的失效模式就很难分析全面。最后我们梳理出来的系统边界图大概是这样的：

定义好边界之后，我们开始逐一分析每个模块可能的失效模式，以及失效后对整个系统的影响。

失效模式分析过程

我们先从电源模块开始分析。电源模块最明显的失效模式是"输出电压异常"，这可能导致供电不足或者电压过高。但这只是常规思路，当我们深入讨论的时候，有人提出了一个更有意思的问题：如果电源模块的输出电压是缓慢下降，而不是突然断电，会发生什么？

这个问题引发了热烈的讨论。最后我们发现，主控板在电压降低到一定程度时，会触发复位程序。但问题是，复位需要一定时间，而在这段时间内，IO模块可能已经采集到了错误的信号并且执行了错误的动作。比如，一个正在上升的工件可能因为执行机构突然停止而掉落，或者一个正在关闭的阀门可能停在中间位置造成泄漏。

顺着这个思路，我们又发现了更多问题。比如通讯模块，如果网络出现闪断，系统是不是能够正确处理？主控板复位后，IO模块的状态是保持还是恢复默认值？这些问题单独看每个模块可能都不致命，但组合在一起就可能导致严重的生产事故。

在分析驱动模块的时候，我们遇到了一个棘手的问题。驱动模块负责控制一个气动阀门，这个阀门在正常情况下应该是快速开启或关闭的。但我们发现，如果控制信号出现异常，阀门可能会停在中间位置。这个失效模式单独来看，影响范围有限——最多就是该关的没关严，或者该开的没开到位。

但当我们把它跟主控板的失效模式联系起来分析时，问题就严重了。如果主控板在发送控制信号的过程中突然复位，而此时阀门正在关闭途中，复位后的主控板可能会认为阀门已经关闭成功，但实际上是半开状态。这个后果就严重了——在某些工艺流程中，半开的阀门可能导致整批产品报废，甚至引发安全事故。

风险评估与改进措施

发现了这些问题之后，我们需要对每个失效模式进行风险评估。在薄云，我们用的是传统的RPN方法，也就是严重度、发生概率和可检测性的乘积。虽然这个方法有很多争议，但在实践中它确实能够帮助我们排列优先级。

下面这个表格展示了我们评估后认为风险最高的几个失效模式及其改进措施：

大家可以看到，通过这些改进措施，风险等级有了明显的下降。尤其是第一个失效模式，它的RPN从168降到了48，这个降幅是相当可观的。当然，RPN的数值只是参考，真正重要的是我们确实识别出了潜在的问题并且采取了措施。

实战中最容易踩的几个坑

在做系统FMEA的这几年，我和薄云的同事们总结了一些容易踩的坑。这些坑我们在不同的项目中反复看到，有些甚至是行业通病。今天趁这个机会，我给大家分享出来，希望能帮大家少走一些弯路。

第一个坑是把FMEA当成一个人的工作。前面我已经提到了跨职能的重要性，但这里我想强调的是，不仅仅是职能要跨，专业程度也要有一定的跨度。如果一个团队里全是同类型的人才，就算人多，也很难发现深层次的问题。我们有次做FMEA，团队清一色是控制算法工程师，结果漏掉了不少机械和电气层面的问题。后来我们加入了机械工程师和现场应用工程师，分析的深度明显不一样了。

第二个坑是只分析正常情况下的失效模式。很多人在做FMEA的时候，只会考虑系统在正常工况下可能出现的问题。但实际上，很多严重的失效都是在异常情况下发生的。比如电源电压异常、通讯线路受到干扰、温度超出规格范围，这些异常情况往往是被忽略的重点。我们在薄云现在的做法是，在分析完正常情况后，专门留出时间来讨论各种"极端假设"——如果这个参数超了10倍会怎样？如果信号线断了但没完全断会怎样？如果同时发生两个失效会怎样？这些问题有时候能发现意想不到的风险点。

第三个坑是只分析直接的因果关系。也就是说，只考虑A坏了导致B出问题，而没有考虑到A坏了可能导致C也出问题，然后B和C一起出问题可能引发更严重的后果。系统FMEA的特点就是要在系统层面看问题，如果只分析单个模块的失效，那就退化成模块级FMEA了。我们现在的做法是在识别出失效模式后，画一张简单的因果链图，看看失效会怎么传播，可能会影响到哪些其他部分。

第四个坑是FMEA做完就归档再也不看了。这真的是一个很浪费的做法。产品开发是一个动态的过程，设计会不断修改，新的失效模式可能会出现，原有的措施可能需要更新。如果FMEA只是一份静态的文档，那它的价值就大打折扣了。我们在薄云的做法是把FMEA当成一个活文档，每次设计变更时都要回顾相关的失效模式，看看需不需要更新。每一个版本都有记录，这样回头看的时候也能知道思路是怎么演变的。

关于FMEA时机的一些思考

什么时候做FMEA最好？这个问题没有标准答案，但我个人的经验是：宜早不宜晚。在概念阶段就开始做FMEA，可以避免很多后期的大返工。但太早的话，系统架构还没有确定，做FMEA也缺乏具体的对象。

我们的做法是在系统架构确定之后、详细设计开始之前，做一次系统级的FMEA。这次FMEA的重点是分析各个子系统之间的接口和交互关系。然后在详细设计阶段，针对每个子系统再做一些补充分析。这样分阶段做的好处是，既不会因为信息不足而流于形式，也不会因为时间太紧而草草了事。

另外，FMEA不是一次性的工作。在产品开发的各个关键节点，都应该回顾和更新FMEA。比如方案评审之后、样机测试之前、试产之前，这些都是很好的回顾时机。我们通常会在这些节点安排专门的FMEA回顾会议，不是重新做一遍，而是看看有没有新的失效模式需要加入，原有的措施是不是仍然有效。

写到最后

不知不觉已经聊了这么多。系统FMEA这个话题真的展开来讲，可以聊的东西太多了。今天我主要是结合我们在薄云的实践经验，跟大家分享了一些做法和思考。中间提到的那些坑，很多都是我们亲身踩过之后总结出来的，希望对大家有参考价值。

FMEA这个方法论已经存在了很多年，在很多行业都有成功的应用。但我想强调的是，方法论只是工具，真正发挥作用的是使用工具的人。如果只是机械地填表格、走流程，那FMEA就失去了它的意义。只有真正去思考、去讨论、去做假设验证，FMEA才能成为保障产品质量的有力手段。

如果你正在做系统FMEA，或者打算在你的团队里推行这个方法，我的建议是：不要着急，从一个小项目开始试点。不要追求一开始就覆盖所有方面，先把几个关键的失效模式识别出来，采取措施，看到效果，然后再逐步推广。实践出真知，有些东西只有自己做过了，才能真正理解其中的门道。

好了，今天就聊到这里。如果有什么问题或者不同的看法，欢迎一起交流。