FMEA FTA联合分析项目工程 - 第4节
4. FTA入门
功能分析这步，说白了就是回答一个问题：这个产品/过程，到底要干什么？
我见过不少团队，一上来就急着找失效模式。结果呢？分析到一半发现大家说的根本不是同一个功能。嗯，这坑我踩过。
3.1 功能定义的颗粒度
功能不能写得太粗，也不能太细。我个人的习惯是：一个功能对应一个可验证的工程要求。
| 层级 | 示例（汽车门锁系统） | 评价 |
|---|---|---|
| 系统级 | 锁止车门 | 太粗，无法分析 |
| 功能级 | 接收到遥控信号后，驱动电机旋转至锁止位置 | 合适 |
| 零件级 | 电机输出轴旋转90° | 太细，适合DFMEA下一层 |
我的经验：写功能时，把“在什么条件下，做什么事，输出什么”写全。比如“当车速>5km/h时，自动落锁”。这样后面做失效分析才不会跑偏。
3.2 功能分析的输出物
功能分析做完，你应该拿到两样东西：
- 功能树/功能网——展示功能之间的层级和依赖关系
- 参数图（P-Diagram）——区分理想功能、噪声因素、控制因素
我个人偏爱功能网，因为它能直接衔接到下一步的失效网。
第四步：失效分析——失效网与失效链
功能分析做完，接下来就是重头戏了。失效分析的核心，就是把每个功能的“反面”找出来。
你想想看，如果一个功能是“车门在车速>5km/h时自动落锁”，那它的失效是什么？很简单：该落锁时不落锁，或者不该落锁时乱落锁。
4.1 失效模式的定义
失效模式要遵循一个原则：一个功能对应一个或多个失效模式。我习惯用“否定功能+具体条件”的方式来写。
功能：当车速>5km/h时，自动落锁
失效模式1：车速>5km/h时，未落锁（功能丧失）
失效模式2：车速≤5km/h时，意外落锁（功能过度）
失效模式3：落锁后立即自动解锁（功能不稳定）
4.2 失效网——把失效串起来
失效网，说白了就是把功能网里的每个功能节点，替换成对应的失效模式。然后问三个问题：
- 上一层的失效是什么？（后果）
- 同一层的失效是什么？（失效模式本身）
- 下一层的失效是什么？（原因）
我在项目中遇到过最典型的情况：团队花了两小时争论“电机卡死”到底是原因还是后果。其实只要画个失效网，一目了然。
4.3 失效链——追根溯源
失效链和失效网的区别在哪？失效网是静态的，展示所有关系；失效链是动态的，展示一条具体的因果路径。
举个例子，你分析“车门未锁止”这个后果，顺着失效链往下挖：
- 后果：车门未锁止 → 乘客有坠落风险
- 失效模式：车速>5km/h未落锁
- 直接原因：控制器未输出驱动信号
- 根原因：轮速传感器信号异常，控制器误判车速为0
我曾经踩过的坑：做失效链分析时，团队容易跳级。比如直接从“车门未锁止”跳到“传感器坏了”，跳过了中间的执行器失效和控制器失效。这样会导致漏掉重要的中间环节。记住：一步一个台阶，别跳级。
4.4 失效分析的输出物
这一步做完，你应该能拿出：
- 失效网图（从功能网映射而来）
- 每条失效链的完整路径（后果→失效模式→原因→根原因）
- 失效模式清单（每个功能对应的所有失效模式）
我个人习惯在失效网图上用颜色标注：红色标后果，紫色标失效模式，橙色标直接原因，青色标根原因。这样评审时一眼就能看出分析深度够不够。
一个小技巧：失效分析时，每个失效模式至少问5次“为什么”。第一次问出来的往往是表象，第五次问出来的才是根原因。我在一个电机卡死案例里，问到第三次才发现是轴承润滑脂选型错误——前面两次都在说“装配不良”“来料不良”，太笼统了。
4.5 常见误区
| 误区 | 表现 | 纠正方法 |
|---|---|---|
| 功能写得太粗 | 一个功能对应十几个失效模式 | 拆细功能，每个功能只对应2-3个失效模式 |
| 失效模式写成了原因 | “电机卡死”写成失效模式 | 失效模式是“功能未实现”，电机卡死是原因 |
| 失效链跳级 | 直接从后果跳到根原因 | 逐层追问，每层只问“直接原因是什么” |
| 忽略功能过度 | 只分析“该做的不做”，不分析“不该做的做了” | 每个功能都问：会不会过度？会不会误动作？ |
嗯，功能分析和失效分析这两步，是FMEA最见功力的地方。你想想看，功能网画得清，失效网就搭得牢；失效网搭得牢，后面的风险分析和改进措施才有根有据。别急，慢慢来，把这两步走扎实了，后面的路就好走了。