2. 故障诊断基础：FMEA与FTA在呼吸机中的应用
各位同学，大家好。今天我们来聊聊故障诊断的底层逻辑。说白了，就是回答两个问题：「这东西会怎么坏？」 和 「坏了会怎样？」。
我在呼吸机研发一线干了十几年，见过太多「设计时觉得没问题，一上临床就出幺蛾子」的案例。嗯，要避免这种尴尬，就得靠两样工具：FMEA（故障模式与影响分析） 和 FTA（故障树分析）。今天我就把这两个家伙在呼吸机上的用法，掰开了揉碎了讲给你听。
2.1 什么是FMEA？—— 先问「会怎么坏」
FMEA，全称 Failure Mode and Effects Analysis。我个人的习惯是把它叫做「找茬大会」。它的核心思路很简单：把系统拆成零件，逐个问「这个零件如果坏了，会有什么后果？」
你想想看，呼吸机这东西，任何一个环节出问题，都可能要命。所以FMEA在呼吸机设计里，是强制要求做的。
2.1.1 FMEA的三大要素
做FMEA，你得盯住三个数字：
- 严重度（S）：后果有多严重？1分（没影响）到10分（致命）。
- 发生度（O）：发生的概率有多大？1分（几乎不可能）到10分（必然发生）。
- 探测度（D）：出问题了，我们能及时发现吗？1分（肯定能发现）到10分（根本发现不了）。
然后算一个 RPN（风险优先级数）：RPN = S × O × D。RPN越高，越要优先处理。
我遇到过的一个真实案例：
有一次，我们设计一款新的涡轮供气模块。FMEA分析时发现，涡轮的轴承如果磨损，会导致供气流量波动。严重度S=8（可能造成患者缺氧），发生度O=4（轴承寿命测试有数据支撑），探测度D=3（流量传感器能捕捉到）。RPN=8×4×3=96。这个值不算低，我们立刻加了冗余轴承和实时振动监测。后来临床反馈，确实有2台机器因为轴承问题被提前预警了。你看，FMEA没白做。
2.1.2 呼吸机FMEA实战表格
下面这张表，是我当年做项目时常用的模板。你直接拿去用就行。
| 组件 | 故障模式 | 可能原因 | 影响 | S | O | D | RPN | 改进措施 |
|---|---|---|---|---|---|---|---|---|
| 氧传感器 | 输出漂移 | 老化、污染 | 氧浓度不准 | 7 | 5 | 4 | 140 | 定期校准、双传感器冗余 |
| 呼气阀 | 卡滞 | 异物、膜片老化 | PEEP异常 | 9 | 3 | 6 | 162 | 增加自检程序、使用医用级材料 |
| 流量传感器 | 堵塞 | 冷凝水、分泌物 | 潮气量不准 | 8 | 6 | 5 | 240 | 加热管路、增加排水机制 |
避坑指南： 我曾经犯过一个错——只盯着「硬件」做FMEA，忽略了「软件逻辑」。比如，呼吸机的报警阈值设置不当，也算一种故障模式。后来我学乖了，每次做FMEA，软件工程师必须到场。
2.2 什么是FTA？—— 再问「为什么会坏」
FMEA是自下而上（从零件到系统），而FTA（故障树分析）是自上而下（从系统到零件）。它用一棵「树」来追溯故障的根本原因。
我个人觉得，FTA更像侦探破案。你发现一个症状（比如「病人端压力过高」），然后一层层往下挖，直到找到最底层的「元凶」。
2.2.1 故障树的基本符号
画故障树，你得认识这几个符号：
- 顶事件：最不想看到的结果（比如：呼吸机停止送气）。
- 中间事件：中间环节。
- 底事件：最根本的原因（比如：电源线脱落）。
- 与门：所有条件同时发生，结果才发生。
- 或门：任何一个条件发生，结果就发生。
2.2.2 呼吸机FTA实战案例
咱们来拆一个真实场景：「呼吸机无法启动」。
为什么会这样？我带你画一遍故障树：
顶事件：呼吸机无法启动
|
+-- 或门 --
| |
| +-- 电源故障
| | |
| | +-- 或门 --
| | |
| | +-- 电源线脱落
| | +-- 保险丝熔断
| | +-- 内部电源模块损坏
| |
| +-- 主控板故障
| | |
| | +-- 或门 --
| | |
| | +-- 软件死锁
| | +-- 硬件损坏（如电容爆浆）
| |
| +-- 安全互锁触发
| |
| +-- 与门 --
| |
| +-- 氧浓度异常
| +-- 压力传感器故障
| +-- 自检程序判定为「不可恢复」
注意： 这里有个关键点——「安全互锁触发」用了与门。意思是：必须同时满足氧浓度异常、压力传感器故障、自检判定不可恢复这三个条件，机器才会锁死不让启动。这是设计上的安全策略，防止误触发。我见过有些工程师把这里画成或门，结果机器动不动就锁死，临床医生骂娘。
2.3 FMEA与FTA的配合使用
你可能会问：这两个工具，到底先用哪个？
我的经验是：先做FMEA，再做FTA。
- FMEA 帮你列出所有可能的故障模式，相当于「广撒网」。
- FTA 帮你针对高风险的故障模式，深挖根本原因，相当于「重点突破」。
举个例子：FMEA发现「流量传感器堵塞」的RPN高达240（很高）。那好，我们就针对这个事件，专门画一棵故障树，看看堵塞到底是怎么发生的——是冷凝水？是分泌物？还是过滤器失效？然后针对每个底事件，制定对策。
我个人的工作流：
- 开FMEA会议，拉上硬件、软件、测试、临床工程师，一起过一遍所有组件。
- 挑出RPN > 100的项目。
- 对每个高风险项目，画FTA故障树。
- 根据故障树，补充测试用例和报警逻辑。
这套流程，我用了十年，救了不少项目。
2.4 总结与避坑
好了，今天的内容就这些。最后给你三个「我曾经」踩过的坑：
- 我曾经 以为FMEA做一次就够了。后来发现，设计改了，FMEA必须跟着改。否则就是废纸一张。
- 我曾经 把FTA画得太复杂，底事件列了上百个，根本没法落地。后来我学乖了，只追到「能直接采取行动」的那一层。
- 我曾经 忽略了「人为操作错误」这个故障模式。比如护士不小心把模式旋钮拧到了「待机」。现在我的FMEA里，一定会有一行叫「操作失误」。
记住：FMEA和FTA不是用来应付检查的文档，而是用来保命的工具。 你花在分析上的每一分钟，都可能在未来救一条命。
下一章，我们会聊聊如何把这些分析结果，变成真正的报警逻辑代码。到时候见。