基于故障树分析的饮水机防干烧可靠性设计与仿真验证

简介：《基于单片机的饮水机防干烧控制系统设计与仿真》PDF文档面向电子信息、自动化及单片机课程设计与毕业设计读者，聚焦饮水机加热系统防干烧可靠性不足的问题。内容以STC89C52为核心，先通过故障树分析法（FTA）梳理加热水箱缺水、传感器无反馈、继电器无法断开等失效路径，求出最小割集并判断底事件结构重要度，再据此优化液位传感器选型与安装位置、温度传感器冗余及三单元继电器触点串联方案，并给出LCD12864显示、声光报警、电源与驱动电路设计及Proteus调试仿真思路。包内共1个PDF文件，约1.27MB，适合作为课设、毕设和电子设计竞赛的参考资料，也可用于理解可靠性分析与单片机控制系统落地过程。目前已有184人学习，可帮助读者快速把握从故障树分析到硬件软件实现、仿真验证的完整设计脉络。

1. 防干烧的可靠性：为什么“多加一个传感器”反而可能是错的设计

饮水机干烧这件事，直觉上的解法很朴素：加个水位开关，缺水就断电。但真实世界里防干烧失效的原因往往不是“没检测”，而是检测链路中的某一环在长期使用后悄悄退化——浮球被水垢卡死、继电器触点熔焊粘在一起、温度传感器引线松脱。这类失效的特点是不报警、不提示，系统照常加热，直到水箱烧红。所以防干烧设计的核心问题不是“要不要检测”，而是“哪一环断了系统还能不能兜住”。这篇文章拆的就是一套把可靠性分析放在电路设计之前的思路：先用故障树分析（FTA）算出最小割集，找出结构重要度最高的底事件，再针对性地做硬件冗余和软件判据，最后用 Proteus 把四种工况跑一遍。搞懂这套推演顺序，比记住某个型号的传感器有用得多。

2. 故障树分析：干烧的最小割集是怎么算出来的

2.1 先建故障树，再谈改电路

大多数防干烧方案是“想到什么加什么”，而这份设计的第一步是把系统拆成一个有向的失效逻辑图。顶事件 T1 定为“饮水机发生干烧”，向下演绎出三个中间事件：M1 加热水箱缺水、M2 加热器处于加热状态、M3 没有及时加水。再往下到底事件，一共五个：X1 液位传感器无反馈、X2 无声音提醒、X3 无警示灯光提醒、X4 温度传感器无反馈、X5 继电器无法断开。

这个树的结构值得琢磨。顶事件由 M1 和 M2 同时成立才发生——缺水本身不危险，缺水且加热器还在通电才危险。而 M3 挂在 M1 之下，意味着“没及时加水”是缺水的成因之一，和传感器失效构成或门关系。把“人为忘记加水”这种软因素也纳入形式化分析，是这套方法比拍脑袋加器件更有说服力的地方。工程上常见的做法是画完树先用布尔代数化简，得到割集后再检查有没有冗余路径——这一步不做，后面的冗余设计就无从判断该加在哪。

2.2 四个最小割集与结构重要度排序

对故障树做定性分析，得到全部最小割集共四组：

最小割集的数量直接回答了“有几种方式会烧起来”：四种。阶数越低越危险——一阶割集意味着单个器件失效就出事，这里最低是二阶，说明原设计至少还需要两个独立失效同时发生才会干烧。但二阶不等于安全，因为 X1 和 X4 可能共享同一路电源或同一个安装环境，实际相关性远高于形式上的独立。

由割集推出结构重要度：I(X1) > I(X5) = I(X4) > I(X3) = I(X2)。液位传感器无反馈排在第一位，因为它出现在两个割集里；继电器粘连和温度失效并列第二，各自出现在两个割集里，但组合对象不同。声光提醒排在末位，因为要它俩同时失效才构成路径——这也解释了为什么最终的声光模块是“锦上添花”而非“雪中送炭”。

提示：结构重要度只反映事件在故障树中的位置，不含失效率数据。真正做定量分析还要乘上各底事件的概率，工程上如果拿不到厂家失效率，用结构重要度定优先级是务实的妥协。

2.3 为什么选 FTA 而不是 FMEA

FMEA 是自下而上的：逐个器件问“它坏了会怎样”，适合发现单点失效。FTA 是自上而下的：从“烧起来了”反推所有可能的组合路径，适合回答“系统还有没有漏掉的失效组合”。防干烧这类安全功能，失效后果高度集中（都是干烧），用 FTA 能把多器件耦合的路径显式列出来，最小割集就是一份可核对的清单。代价是建树时对系统理解要求高，边界条件没定清楚，树就会画歪。这份设计把“初始状态为开关闭合、加热器处于加热状态”和“不容许外来因素致系统失效”写进边界条件，就是在收窄分析范围，避免树无限膨胀。我一般会这么理解：FMEA 是体检，FTA 是事故复盘，安全相关的设计两个都得做，但顺序上先 FTA 定架构、再 FMEA 补细节更省事。

3. 可靠性设计落地：冗余加在哪里、怎么加

3.1 液位检测前移与电容式选型

结构重要度最高的是 X1，所以改动的第一刀切在液位检测。原方案的浮球式传感器有两个血泪问题：体积大、安装受限于水箱结构；长期浸泡结水垢后浮球卡死，卡在“有水”位置时系统会一直加热，这是典型的隐性失效——它不报错，只是不再说真话。

换用非接触式电容液位传感器（型号 XKC-Y23A-V，5V 供电，检测精度 ±3mm，高低电平输出）解决的是机械卡死问题：没有活动部件，隔着水箱壁检测，水垢影响小。更关键的是安装位置从中水箱前移到加热水箱之前——传感器装在中水箱，缺水信号在水还没流到加热箱时就发出，等于把检测点提前了一个环节。从可靠性角度看，这是把“失效后补救”变成了“失效前预警”，缩短了从缺水到干烧的时间窗口。

/* 液位与温度联合判据的简化逻辑 */ #define LEVEL_LOW 0 /* 电容液位传感器输出低电平表示缺水 */ #define TEMP_DRY 110 /* 干烧判定阈值，单位 ℃ */ #define TEMP_KEEP 85 /* 保温下限 */ unsigned char check_safety(void) { unsigned char level = READ_LEVEL_PIN(); /* 读液位传感器电平 */ int temp = ds18b20_read(); /* 读 DS18B20 温度值 */ if (level == LEVEL_LOW) { /* 一级判据：缺水优先 */ relay_all_off(); /* 立即断开三路继电器 */ alarm_on(ALARM_LEVEL); /* 声光报警，提示加水 */ return STATE_DRY; } if (temp > TEMP_DRY) { /* 二级判据：温度超限兜底 */ relay_all_off(); alarm_on(ALARM_DRY); return STATE_OVERHEAT; } return STATE_NORMAL; }

这段逻辑的重点在判断顺序：液位判据放在温度判据之前，因为液位是“事前”信号，温度是“事后”信号，等温度冲到 110℃ 时水可能已经烧干了。relay_all_off()一次断三路而不是断一路，对应的是后面要讲的串联冗余结构。参数上TEMP_DRY设 110℃ 而非 100℃，是给高原地区低沸点和传感器误差留余量；TEMP_KEEP85℃ 则对应保温工况的黄绿灯切换。

3.2 三继电器串联：为什么串联实现了并联的可靠性

这是整份设计里最反直觉的一处。受继电器触点熔焊（粘连）失效模式影响，原方案单个继电器一旦粘死，加热器就永久通电。常规思路是并联两个继电器“互为备份”，但并联在防干烧场景下是错的：并联要求两个都断开才断电，任一触点粘连就失效，可靠度反而下降。

改成三单元触点串联后，逻辑反过来了：正常加热时三个触点都闭合；需要断电时，只要有一个触点能正常断开，回路就断了，防干烧功能生效；只有三个触点全部粘连，才会失效。电路上是串联，功能上等效于三个“断开能力”并联。温度传感器同理采用两路 DS18B20 并联采集，-55℃~+125℃量程，传感器 A 和 B 同时对加热水箱测温，软件取合理值判断。

代价也要说清楚：三个继电器线圈要同时驱动，单片机 I/O 口灌电流不够，所以每一路都配了 NPN 三极管做驱动，R14~R16 是偏置电阻，保证关断时可靠截止；线圈两端各并一只续流二极管（D4~D6），给断电瞬间的感性反电动势提供泄流通路，否则三极管会被击穿。加热器额定 220V、约 500W，工作电流约 2A，继电器触点最大切换电流 10A，余量足够。

注意：串联触点带来一个副作用——三路驱动的时序如果不同步，会出现短暂的单点导通状态。软件上应当三路同时置位，不要在中断里分批操作。

4. 硬件链路与 Proteus 仿真：怎么验证防干烧真的有效

4.1 从 220V 到 5V：供电与显示链路的可靠性细节

主控用 STC89C52，外围分五块：电源、温度检测、液位检测、继电器驱动、人机交互。电源从 220VAC 经变压器降压、1N4007 桥式整流、LM7805 稳压出 5VDC，供给单片机、传感器、LCD 和驱动电路。这条链路上任何一环虚焊，整机就失去防干烧能力——这也是为什么 FTA 里把“外来因素致系统失效”排除在边界外，否则树会长到无法分析。

显示用 AMPIRE 12864 汉字图形液晶，KS0108 控制器，5V 驱动。它分左右两个半屏，CS1、CS2 分别接 P2.3、P2.4 做片选，RS、R/W、E 接 P2.0~P2.2，8 位数据口 DB0~DB7 接 P0.0~P0.7。这里有个容易翻车的点：51 单片机的 P0 口是漏极开路结构，做通用 I/O 输出时必须外接上拉电阻（图中 RP1 为 1k 排阻），否则驱动电平拉不高，液晶会出现花屏或整屏不亮。每个半屏 64×64 位、512 字节缓存，分 8 页 64 列，写显存时要先算页地址再算列地址。

声光报警部分，单片机 I/O 直接驱动蜂鸣器和 LED 电流不够，蜂鸣器用 PNP 三极管驱动（5V 工作电压），LED 用 NPN 三极管驱动（2.2V / 10mA），R4~R7 限流、R11~R13 分压。这些电阻值不是随手写的：限流电阻偏小会烧 LED，偏大会导致亮度不足、在强光环境下警示失效，而警示恰恰是故障树里 X2、X3 两个底事件的直接对策。

4.2 四种工况的仿真设定与观察点

仿真在 Proteus 里搭，两个替换必须做：电容液位传感器输出的是开关量，仿真中用开关代替；单刀单掷继电器在仿真里看不到触点动作，换成带 Animated Relay model 描述的继电器，靠观察掷刀摆动判断通断；加热元件用 heater 模型并设好参数。这样做的目的是让“断电”这个动作在画面上可见——否则仿真跑通了也不知道是软件逻辑对还是模型默认通。

工况设定四档，正好覆盖软件流程图的分支：

• 水温 ≤ 85℃，黄灯亮，加热中；
• 85℃ < 水温 ≤ 110℃，绿灯亮，保温；
• 水温 > 110℃，红灯亮 + 蜂鸣器报警，继电器断开；
• 液位低，红灯亮 + 蜂鸣器报警，继电器断开。

调试时手动拨动水位开关、修改 DS18B20 的注入温度值，观察对应继电器的掷刀是否摆到断开位，同时看 12864 上“缺水”“干烧”字样和“加水”提示是否同步出现。这套验证方法的局限也要认清：Proteus 验证的是逻辑正确性，验证不了触点粘连、水垢、电源纹波这些物理失效——那些恰恰是 FTA 分析的起点。所以仿真是必要不充分条件，样机老化测试不能省。

5. 冗余的代价：安全设计里那些不能只看的指标

把三继电器串联、双温度传感器并联、液位检测前移这三件事放在一起看，会发现它们各自增加了成本、功耗和故障点数量。串联三个继电器意味着三倍的线圈功耗、三倍的驱动电路、三倍的接线端子，任何一处虚焊都会让“正常加热”这个功能失效——注意，是正常加热失效，不是防干烧失效。这是一个典型的安全性与可用性的取舍：系统变得更“容易不工作”，但更不“容易烧起来”。在防干烧这种失效后果不可接受的场景里，这个方向是对的；但如果换成用户对“随时有热水”极度敏感的产品，三串结构就可能被投诉淹没。

第二个取舍是检测前移的边界。传感器装在中水箱能提前预警，但它测的不是加热箱的真实水位，中间隔着管路和流量。如果中水箱有水、管路堵塞，加热箱依然可能干烧，此时只能靠温度判据兜底。所以液位前移不是替代温度检测，而是把两道判据的时间差拉开——这也是为什么软件里液位判据优先级高于温度判据，两者不能互相取代。

第三个取舍在仿真验证的深度。Proteus 能跑通四种工况，说明逻辑闭环成立，但触点粘连、传感器漂移、上拉电阻在高温下的阻值变化，这些只能靠实物测试暴露。我的习惯是：凡是涉及安全断电的设计，仿真通过后必须再做一轮“拔线测试”——运行中逐个拔掉传感器和驱动线，看系统是不是每次都进入安全态。这套动作做一遍，比看十遍流程图更能让人放心。

从那以后我每次碰这类安全相关的控制设计，都会强制走一遍“故障树 → 最小割集 → 冗余落点 → 拔线验证”的流程，哪怕时间紧也至少把最小割集列出来，因为它能告诉你哪个器件坏了会真的出事。希望帮到你。

本文还有配套的精品资源，点击获取