简介：《基于单片机的饮水机防干烧控制系统设计与仿真》是一份面向电子、自动化专业学生及家电控制设计人员的PDF技术文档，聚焦传统饮水机防干烧可靠性不足的问题。内容以故障树分析法（FTA）为主线，先确定顶事件与边界条件、求出导致干烧的最小割集，再据此优化液位传感器、温度传感器和继电器模块，并给出STC89C52主控、电源、显示、声光警示及继电器驱动等硬件电路设计，最后通过Proteus完成调试与仿真验证。压缩包内为1个PDF文件，大小约1.27MB，便于检索和离线阅读。已有184人学习，适合课程设计、毕业设计或相关工程方案参考，可帮助读者理解从可靠性分析到电路实现与仿真验证的完整思路，并掌握非接触式液位检测、三继电器触点串联等具体设计方法。

1. 从「温度超了就断电」说起：这套防干烧方案要解决什么

做基于单片机的饮水机防干烧控制系统设计与仿真，最容易翻车的地方不是写不出代码，而是把「防干烧」当成一个 if 判断——温度超了就断电。真到答辩，问一句「液位传感器坏了怎么办」，方案立刻站不住。这套方案换了个起点：先用故障树分析法把「饮水机干烧」这个顶事件往下拆，拆出 4 条最小割集，再让每条割集对应一项具体的硬件或软件措施——液位检测前移到中水箱、温度双路并联、三只继电器触点串联、声光报警补齐。主控用 STC89C52，执行层用继电器控制 500W 加热器，最后在 Proteus 里把缺水、干烧、保温、加热四种工况跑通。适合做单片机课程设计、毕业设计，也适合想把家电控制类题目做出可靠性深度的人。

2. 可靠性分析：用故障树把「干烧」拆成 4 条最小割集

2.1 建树之前先想清楚：为什么不直接做 FMEA

很多同类题目在第一章就直奔硬件选型，顶多补一句「本设计具有较高的可靠性」。这句话没有信息量，因为它没有说明是哪一条失效路径被堵住了。可靠性分析的方法有两类常用做法：FMEA 是自下而上枚举每个元器件的失效模式，再推演后果；FTA 是自上而下，从一个不允许发生的顶事件往回倒推，找出所有能导致它发生的组合。对「防干烧」这类结果导向、且要求穷举组合失效的场景，FTA 更直接——我要回答的问题是「有哪几条路能走到干烧」，而不是「每个器件坏了会怎样」。

建树前先定义三个东西。分析范围锁定在饮水机的加热控制系统，即从中水箱进水、加热水箱加热到继电器通断这一条链路，不涉及制冷、不涉及外部供电质量。顶事件 T1 定义为「饮水机发生干烧」，即加热水箱无水或水量不足时加热器仍在通电。边界条件写两条：初始状态为总开关闭合、加热器处于加热工作状态；不容许事件为外来明火、人为破坏、市电异常等外部因素，这些不纳入树内，否则树会无限膨胀。

从工作原理出发往下演绎：水位信息由液位传感器采集，温度信息由温度传感器采集，两者送入主控，主控再驱动继电器去控制加热器。任何一个环节失效，都可能让控制器「看不见」缺水这个事实，或者「关不掉」加热器。于是顶事件下面挂两个中间事件——M1 加热水箱缺水、M2 加热器仍处于加热状态；M1 下面继续分解为 X1 液位传感器无反馈、X4 温度传感器无反馈，M2 下面分解为 M3 没有及时加水（由 X2 无声音提醒、X3 无警示灯光提醒合成）与 X5 继电器触点无法断开。五个底事件全部是可观测、可干预的物理失效，没有一个是「程序写错」这种无法定量的描述。

2.2 求最小割集：4 条路径和一条重要度排序

树建好后做定性分析，用布尔代数往下展开。按上面的结构，顶事件可以写成：

T1 = (X1 + X2·X3) · (X4 + X5) = X1·X4 + X1·X5 + X2·X3·X4 + X2·X3·X5

展开后得到 4 个最小割集，每一个都代表一条完整的、能独立导致干烧的失效路径：

四阶、三阶的割集在这里没有出现，全是二阶和三阶，说明这套系统的干烧风险并不低——任意两个环节同时出问题就够触发。这正好解释了为什么「只加一个温度判断」的做法不可靠：它只堵住了割集的一部分，X1·X5 这条路径完全敞开。

再看结构重要度。X1 同时出现在两个二阶割集里，是唯一一个「单独失效就能和另一环凑成最短路径」的检测元件；X4、X5 各出现在一个二阶割集和一个三阶割集里，重要性次之；X2、X3 只出现在三阶割集里，必须两个一起失效才有意义，排最后。排序结果是：

I(X1) > I(X5) = I(X4) > I(X3) = I(X2)

这个排序就是后面硬件设计的任务清单。排第一的 X1 决定液位检测必须换方案、换位置；并列第二的 X4、X5 决定温度要做冗余、继电器要做冗余；排在最后的 X2、X3 虽然重要度最低，但仍然在割集路径里，不能省，声光报警必须补齐。

2.3 把割集翻译成设计动作：三条硬件冗余加一条提醒通道

有了排序，设计动作就有的放矢了，不是拍脑袋加器件。

针对 X1，做两件事。第一是换传感器类型：传统浮球式液位开关体积大、安装位置受限，长期泡在水里容易结垢，浮球被卡住就直接失效，属于典型的「一年不出问题、第三年必出问题」。改用基于电容原理的非接触式液位传感器，贴在水箱外壁即可检测，体积小、不接触水体、不结垢，检测精度可以做到 ±3mm 量级。第二是换安装位置：原来传感器装在加热水箱，等加热水箱缺水时才动作，此时加热管可能已经空烧了一段时间；前移到中水箱，中水箱一缺水就提前发信号，把「事后断电」变成「事前预警」。这一条改动不增加成本，但直接把 X1 的触发概率压下去了，性价比最高。

针对 X4，做两路温度传感器并联。两个 DS18B20 同时对加热水箱测温，软件上取两者中的较大值作为判据。这样只要有一路还能正常读出高温，系统就能判定超温并断开加热器——从功能角度看这是并联冗余，可靠性高于单路。针对 X5，做三单元继电器触点串联：三只继电器的触点串在加热器的供电回路里，任意一只触点能断开，回路就断了。触点串联，但防干烧功能是并联的，这跟温度双路是一个道理。三只继电器同时粘连的概率远低于单只，这一条直接堵死了 X1·X5 这条割集。

针对 X2、X3，补声光通道。液位传感器检测到缺水、或温度判据超过干烧设定值时，LCD 显示「缺水」或「干烧」并提示「加水」，蜂鸣器鸣叫，红色 LED 闪烁。这条通道的价值不在于自动断电，而在于把「没人知道」这个中间事件 M3 掐掉，让割集 3 和割集 4 失效。

提示：故障树不是画完就挂墙上的装饰。每个底事件后面必须能对应到一条具体的电路改动或代码分支，否则这棵树就只是答辩 PPT 里的一张图。

3. 硬件架构设计：一颗 STC89C52 带五路模块的划分与选型

3.1 系统框图：五路输入输出围绕主控展开

整套硬件以 STC89C52 为核心，向外分五路：电源电路、检测电路（温度两路 + 液位一路）、显示电路（LCD12864）、报警电路（蜂鸣器 + 三只 LED）、执行电路（三路继电器驱动 + 加热器）。画框图时建议按信号流向分层，而不是按器件罗列：左边是传感器层，中间是主控层，右边是执行与显示层，最下面是电源层贯通全场。这样画的图，答辩时一眼就能讲清楚「信号从哪来、到哪去、在哪判断」。

引脚分配是整个硬件设计里最先要定死的东西，定晚了后面改代码会连环返工。这套方案用到的分配如下：

具体端口号按实际布线调整，但有一条原则不能改：两片 DS18B20 绝对不能挂在同一根 IO 上。单总线器件靠时序区分通信，两片并在一根线上会同时响应，读回来的大概率是 85℃ 这个上电默认值，看着像正常工作，其实全程没测到真实温度——这是最阴的一类故障。

3.2 电源与主控最小系统

电源从家用 220V 交流取电，经变压器降压后进入由 1N4007 组成的桥式整流电路，再送入 LM7805 三端稳压芯片，输出 5V 直流，为单片机、传感器、液晶、蜂鸣器和继电器驱动电路供电。桥式整流后面要并滤波电解电容，容量按负载电流估，这套系统总电流不大，1000μF 级别够用，但继电器吸合瞬间的浪涌会把电压往下拽，电容太小就会出现「一吸合就复位」的现象。

主控最小系统包括 12MHz 晶振加两只 33pF 瓷片电容、复位电路、以及 P0 口的上拉排阻。P0 口作为通用 IO 使用时是漏极开路结构，驱动液晶数据线必须外接上拉，否则电平拉不高，屏幕会出现随机花屏或者干脆不亮。这个细节在很多原理图里被省略，实物一焊就出问题。

注意：强弱电必须分区布线。220V 加热回路和 5V 控制回路在 PCB 上要拉开距离，继电器下方不要走信号线，否则继电器吸合时的干扰会串进温度采集。

3.3 检测层：液位前移，温度双路

液位检测用非接触式电容传感器，型号可选 XKC-Y23A-V 这一类，5V 供电，检测精度 ±3mm，输出高低电平开关量。安装位置贴在中水箱外壁，低于设定水位时输出缺水信号。它的好处是不与水接触，没有结垢和卡死问题，缺点是对水箱壁厚和材质敏感，塑料壁厚超过一定范围灵敏度会下降，选型时要跟厂家确认适用壁厚。

温度检测用两片 DS18B20，5V 供电，测温范围 -55℃ 到 +125℃，单总线数字输出，省掉了 ADC 和调理电路。两片分别接两个 IO，软件分时读取。DS18B20 的转换时间跟分辨率有关，12 位分辨率下约 750ms，主循环里不能死等，通常的做法是发转换命令后先去处理显示和按键，下一轮再回来读结果；如果图省事直接延时等待，界面会明显卡顿。

两路温度不是简单取平均。取平均的后果是：一路失灵读回 85℃，另一路正常读 25℃，平均下来 55℃，系统认为温度不高，继续加热——冗余直接作废。正确做法是取最大值，只要有一路报高温就按高温处理，宁可误报不可漏报。

3.4 执行层与报警层：三继电器串联与三极管驱动

执行层是三只小型单刀单掷常开继电器，线圈额定电压 5V，触点最大切换电流 10A。加热器额定 220V、功率约 500W，工作电流约 2A，继电器余量充足。三只继电器的触点串联后接入加热器回路，线圈分别由三个 NPN 三极管驱动，基极串偏置电阻，保证关断时可靠截止；线圈两端反并续流二极管，为断电瞬间的感应电动势提供泄流通路，保护三极管不被击穿。这一颗二极管省掉的代价是三极管炸给你看。

报警层的蜂鸣器工作电压 5V，用 PNP 三极管驱动，基极低电平导通；三只 LED 工作电压约 2.2V、电流 10mA，用 NPN 驱动，串限流电阻。单片机的 IO 灌电流和拉电流都有限，直接驱动蜂鸣器和 LED 会出现声音发虚、亮度不足，甚至拉低整个端口电平，所以这里必须加三极管做电流放大，不能省。

4. 软件流程与状态机：从缺水判定到 110℃ 阈值的分级控制

4.1 主循环的判定优先级：水位永远排在温度前面

程序用 C 语言编写，开发环境 Keil μVision4。整个软件的核心是一个无限循环加一套严格优先级的判定顺序，顺序错了，逻辑就全错。

优先级从高到低是：水位判定、干烧判定、保温判定、加热。水位排第一，因为干烧的本质是「没水还在烧」，温度只是干烧的结果表现之一。如果先判温度后判水位，会出现这种情况：水箱已经空了，加热管温度还没升到 110℃，程序认为正常继续加热，等温度上来才断电，这中间的空烧时间就是事故窗口。水位一低立刻断继电器，不等温度。

干烧判定排第二，阈值设在 110℃。这个值不是随便定的：常压下水到 100℃ 就沸腾，加热水箱内的水温正常情况下不会超过沸点太多，一旦测到 110℃ 以上，说明水体已经不存在或者严重不足，此时必须无条件断电。保温判定排第三，上限 85℃，超过就停加热，低于回差下限再恢复。加热是兜底动作，只有前面所有条件都不触发才执行。

4.2 三态阈值与回差：85℃、110℃ 和那 3℃ 的来历

仿真里定义了三种状态，对应三种指示灯：加热时黄灯亮（水温 ≤ 85℃）；保温时绿灯亮（85℃ < 水温 ≤ 110℃）；干烧（水温 > 110℃）或缺水时红灯亮并伴随蜂鸣器报警。

这里必须引入回差。如果只用一个 85℃ 阈值做开关，水温在 85℃ 上下浮动 0.5℃ 时，继电器会以每秒数次的频率反复吸合断开，声音像打点计时器，触点寿命急剧下降。加上 3℃ 回差后，判据变成「≥85℃ 停加热，<82℃ 才恢复加热」，中间形成一个死区，继电器动作次数从每分钟上百次降到个位数。

回差的大小要跟水箱热惯性匹配。水箱容积大、加热功率相对小，温度变化慢，回差可以取 2~3℃；如果水箱很小、加热很猛，回差要放大到 5℃ 以上，否则还是会在死区边缘来回跳。

4.3 关键代码：双路取大、三路同断、缺水多数表决

主循环的结构如下，重点是判定顺序和取大策略。

#define T_DRY 110 /* 干烧判定阈值，单位 ℃ */ #define T_KEEP 85 /* 保温上限，达到即停加热 */ #define T_HYST 3 /* 回差，防止继电器频繁动作 */ void main(void) { unsigned char level_low, t_a, t_b, t_max; sys_init(); /* 时钟、IO、LCD、传感器初始化 */ lcd_show_str(0, 0, "系统自检"); while (1) { level_low = read_level(); /* 1 表示缺水 */ t_a = ds18b20_read(TEMP_A); /* 两路分别读取，不能共用总线 */ t_b = ds18b20_read(TEMP_B); t_max = (t_a > t_b) ? t_a : t_b; /* 取大值，保守判据 */ lcd_refresh(level_low, t_a, t_b, t_max); if (level_low) { /* 水位优先级最高，不等温度 */ heater_off(); alarm_on(ALARM_NO_WATER); continue; } if (t_max >= T_DRY) { /* 干烧，无条件断电 */ heater_off(); alarm_on(ALARM_DRY); continue; } if (t_max >= T_KEEP) { /* 进入保温区，停止加热 */ heater_off(); alarm_off(); } else if (t_max < T_KEEP - T_HYST) { heater_on(); /* 低于回差下限才恢复加热 */ } } }

这段代码有三个设计点值得单独说。第一，t_max取两路温度的较大值，任何一路报高温都会触发保护，这是硬件并联冗余在软件侧必须配套的写法，取平均会让冗余失效。第二，缺水分支用了continue，意味着缺水状态下完全不进入温度判定，避免出现「水位低但温度正常所以继续加热」的错误逻辑。第三，保温分支只关不断，alarm_off()让蜂鸣器静音但保持继电器断开，这样保温过程是安静的，只有真正异常才响。

三只继电器的动作必须同步，这是冗余能否成立的前提。

sbit RELAY_A = P1^4; /* 三路继电器，触点串联在加热回路中 */ sbit RELAY_B = P1^5; sbit RELAY_C = P1^6; void heater_on(void) { RELAY_A = 1; /* NPN 驱动，高电平吸合 */ RELAY_B = 1; RELAY_C = 1; } void heater_off(void) { RELAY_A = 0; /* 三路必须同时断开，只断一路等于没断 */ RELAY_B = 0; RELAY_C = 0; }

硬件上三触点串联，任意一只断开回路就断，所以软件写几路其实不影响断电结果。但要求三路同时写，原因在故障检测：如果某一路驱动三极管已经损坏，它对应的继电器永远不动作，从外部看不出来。保持三路同步动作，在检修时逐路测量线圈电压，就能快速定位是哪一路失效；如果代码里只写一路，另外两路相当于长期闲置，「三取一」就退化成了「一取一」。

液位读取要做软件消抖。电容式液位传感器在水面晃动时输出会抖，直接用单次采样做判据，会在临界水位反复报警。

unsigned char read_level(void) { unsigned char i, cnt = 0; for (i = 0; i < 8; i++) { /* 连续采样 8 次 */ if (LEVEL_PIN == 1) cnt++; /* 极性按实际传感器确认 */ delay_ms(2); } return (cnt >= 6) ? 1 : 0; /* 6/8 多数表决，滤掉瞬时抖动 */ }

8 次采样、6 次确认，等价于 12ms 的观测窗口，既能滤掉水面波纹造成的毫秒级抖动，又不会让响应延迟到影响安全。极性这里要特别小心，不同厂家的传感器「有水输出高」和「有水输出低」都有，接反了会出现一通电就报缺水，这属于接线级错误，不是代码逻辑错误。

4.4 显示与报警的联动

LCD12864 采用 KS0108 控制器，5V 驱动，分左右两个半屏，每半屏 64×64 点阵、8 页 64 列，控制信号为 CS1、CS2、RS、R/W、E。刷屏时要注意先选半屏再写数据，跨屏写会串位。汉字显示用 16×16 点阵，一个字占两页，写的时候先写上半页再写下半页，页地址要跟着改。

显示内容不需要花哨，四个字段够了：当前水温（两路都显示，方便看出哪一路异常）、当前水位状态、当前工作状态（加热/保温/缺水/干烧）、以及缺水时的「请加水」提示。两路温度同时显示是个很实用的设计——调试阶段一眼就能发现某一路读数异常，比事后翻代码快得多。

报警逻辑跟状态绑定：缺水或干烧时红灯闪烁加蜂鸣器间歇鸣叫，保温时绿灯常亮，加热时黄灯常亮。闪烁用计数器在主循环里做，不要用延时死等，否则整个系统会卡在闪灯里，温度采集全部停摆。

5. 避坑与排查：仿真和实物调试里最容易翻车的五处

5.1 仿真里继电器纹丝不动，看不出通断

现象：Proteus 里程序跑起来了，LCD 显示正常，温度也在变，但继电器没反应，也不知道触点到底有没有动作。

原因：Proteus 元件库里的普通继电器模型只有电气特性，没有动画效果，即使线圈得电、触点状态已经改变，画面上也看不出来。很多人据此判断「程序没跑对」，然后去改代码，越改越乱。

解决：仿真时选用带 Animated Relay model 描述的继电器模型，这类模型在触点动作时会有明显的掷刀摆动动画，直接观察摆臂就能判断通断。另外加热元件用 heater 模型而不是普通电阻，能直观看到发热状态。这一条属于工具层面的血泪经验，早点知道能省两天。

5.2 一上电就报缺水，可水箱明明是满的

现象：仿真刚开始，水位开关处于「有水」位置，LCD 却直接显示「缺水」并报警。

原因：电容式液位传感器在 Proteus 里没有对应模型，通常用开关替代。开关的默认状态、以及代码里对高低电平的定义，跟真实传感器的输出极性对不上。真实传感器可能是「有水输出低、缺水输出高」，而仿真开关默认悬空或接地，程序按高电平判缺水，结果一上电就误报。

解决：在代码里把极性做成宏定义，仿真和实物用不同配置；或者在仿真开关两端加明确的上拉/下拉，保证默认状态确定。改完之后，把开关拨到两个位置各测一次，确认显示跟状态一致，再往下做。

5.3 两片 DS18B20 挂在同一个 IO 上，读回来全是 85℃

现象：温度显示恒定为 85℃，无论怎么调仿真里的温度源都不变，或者两路读数一模一样。

原因：DS18B20 是单总线器件，靠严格的时序通信。两片挂在同一根 IO 上会同时响应复位脉冲，数据线上出现线与冲突，主机读到的往往是上电默认值 85℃（这是芯片的 Power-on Reset 值）。这个值看起来很像正常温度，极具迷惑性。

解决：一片一个 IO，软件分时读取，读完一路再做下一路复位。每根数据线单独配 4.7k 上拉电阻。读回值要做合法性判断，85℃ 这个特殊值最好在代码里单独标记，调试时能第一时间发现异常。

5.4 继电器一吸合，单片机就复位或者 LCD 花屏

现象：仿真里正常，实物一上电，每次继电器吸合瞬间屏幕乱码，严重时单片机直接重启。

原因：三个可能叠加。一是继电器线圈断电瞬间的反电动势没有泄流通路，通过电源串回单片机；二是 P0 口没接上拉排阻，驱动液晶时电平不稳；三是电源滤波电容容量不足，线圈吸合的浪涌电流把 5V 拉塌。

解决：线圈两端反并续流二极管，方向不能接反；P0 口加 1k 排阻上拉；电源输出端加大滤波电容，必要时给继电器单独一路供电。排查时用示波器看 5V 轨在继电器动作瞬间有没有跌落，有跌落就是电源问题，没有跌落就是干扰耦合问题，两条路分开查。

5.5 保温状态下继电器「哒哒」响个不停

现象：水温稳定在 85℃ 附近时，继电器以很高频率反复吸合断开，声音密集，触点发烫。

原因：单阈值判断没有回差。传感器分辨率有限，温度在阈值上下微小波动就会让判据反复翻转，这就是典型的开关振荡。

解决：加回差，85℃ 停、82℃ 才恢复，中间设死区。回差大小按水箱热惯性调，热惯性大的取小一点，热惯性小的取大一点。加完回差后如果还振，说明温度采样本身噪声太大，需要在软件里做几次采样取中值再判。

6. 验收与答辩：用一张用例表证明防干烧是真的可靠

6.1 把四种工况扩成六条验收用例

仿真跑通不等于方案成立。真正能拿得出手的验收，是把故障树里的每条割集都变成一条可执行的测试用例，逐条验证措施有效。这套方案我一般按下面这张表来验收：

第 5 条和第 6 条是关键。前四条只证明「正常情况能用」，后两条才证明「出故障时还能用」，而这正是可靠性设计的全部意义。第 6 条在仿真里要把某一只继电器的控制信号强制拉高模拟粘连，然后看加热器回路是否仍然断电——如果断不了，说明串联冗余没接对。

6.2 答辩时三句话讲清楚这套设计

第一句讲问题来源：干烧不是温度问题，是「缺水没被发现」加「加热没被切断」两个条件同时成立。第二句讲方法：用故障树把这两个条件展开，得到 4 条最小割集，X1 液位传感器的重要度最高，所以第一优先级的措施是换传感器加前移安装位。第三句讲验证：每条割集对应一条测试用例，六条用例全部通过，其中两条是故障注入。

这个讲法的好处是，评委随便挑一个器件问「这个坏了怎么办」，你都能顺着故障树答出来：它在哪条割集里、重要度排第几、对应的冗余措施是什么。最怕的是背电路图，问到第三层就露馅。

提示：答辩 PPT 里故障树那一页不要做成密密麻麻的小字。画树，标出 4 个最小割集，用红框圈住 X1，旁边写一句「换非接触式 + 前移中水箱」，比十行说明都管用。

从那以后我每次做带保护功能的控制系统，都会强制走一遍「先建树、再定措施、最后按割集出用例」这个流程，哪怕只是个小课设。因为跳过这一步，最后验收时你会发现，除了证明「它能正常工作」，你拿不出任何东西证明「它出故障时还安全」。希望帮到你。

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