智能马桶设计方案：电气架构、即热PID控温与固件状态机

简介：这份文档资料面向电子信息、自动化及FPGA方向的课程设计学习者，围绕智能马桶控制系统给出一套完整设计方案，适合需要完成综合性课题或参考智能卫浴控制思路的读者。资源包共1个文件，为单份doc文档，整体约383KB，内容包含任务描述、课题背景、方案设计与硬件电路设计等章节，可对应到操作面板按键定义、臀部洗净与女用洗净流程、座温水温风温三档调节、入座除臭与红外夜灯控制等具体功能指标。方案主体以FPGA为控制核心，给出系统总体框图，并按温度控制、电机工作等模块展开，涉及PT100铂热电阻测温电桥与差分放大、A/D转换、双向可控硅加热驱动、光耦隔离以及PWM占空比调速驱动电磁阀等电路细节，同时包含外围电路绘制与波形说明的课程设计要求。目前已有306人学习，可为读者提供从功能分解到模块电路实现的完整参考路径，便于对照整理报告与验证设计要点。

1. 一份智能马桶设计方案文档，真正卡人的从来不是功能列表

多数人翻开《某智能马桶设计方案.doc》，第一眼扫的是功能清单：即热冲洗、暖风烘干、除臭、夜灯、遥控、APP 联动。功能谁都会写，真正决定这个项目能不能开模、能不能过检、能不能量产的，是附录里那串不起眼的数字——漏电保护动作电流、水温上限、座圈温升速率、喷嘴复位重复精度、强弱电之间的爬电距离。这份文档本质上是结构、硬件、固件、测试四条线之间的接口合同，任何一条线读不懂这些数字，后面都要靠改模、飞线和补丁来还债。下面按需求边界、电气与传感链路、固件落地、量产验证的顺序，把一份能打样的智能马桶方案该写什么、参数怎么定、代码怎么落讲清楚，读者对象是做智能卫浴和小家电的嵌入式、硬件与测试工程师。

2. 需求边界与电气架构：智能马桶方案文档的第一层怎么拆

2.1 功能分区：先把整机切成五个能独立验证的模块

写方案最容易犯的错，是把整机当成一个黑盒来描述，最后谁也不知道哪条线该先动手。我的习惯是先在文档里把智能马桶切成五块：座圈加热模块、水加热与喷淋模块、干燥与除臭风路模块、人机交互模块、主控与电源安全模块。每个模块在方案里必须交代四件事：输入是什么（市电、水温、水流、按键、总线指令）、输出是什么（热量、水柱、风量、屏幕、状态帧）、典型功耗与峰值功耗、以及单点失效后的行为。

单点失效这一栏最容易被跳过，却最值钱。座圈 NTC 断线了，是停加热还是按固定占空比运行；流量计卡死在某个读数上，是拒绝启动即热还是降功率冲洗。把这些写清楚，固件的故障码表基本就自动成型了。方案文档里给每个模块配一张"输入—输出—失效模式"的表，评审时结构、硬件、软件三方各看一遍，比开三次会都管用。

2.2 电气架构与水电分离：220V 侧和 3.3V 侧怎么划

智能马桶方案里最不能含糊的就是电源分区。整机通常只有一路市电进线，从进线到 MCU 至少要穿过三级：进线保护、隔离降压、低压稳压。我把这三级的边界和器件写进文档时，一般会做成下面这样一张表，硬件照着画原理图，结构照着留爬电间距，测试照着做耐压。

分区定完之后，方案里必须写死两条硬约束：一是强弱电在 PCB 上的分区与开槽位置，爬电距离和电气间隙要留够余量，加强绝缘一般比基本绝缘更保守；二是结构上实现水路与电路物理分离，喷淋水路走独立腔体，接插件做防水处理，整机满足 IPX4 级别以上的防溅要求。这两条不写进方案，等到做认证再补，代价通常是重开一套模具。

2.3 即热功率估算：先用脚本把加热体规格算出来

即热式机型的加热体选型不该拍脑袋，它由流量和目标温升直接决定。方案文档里给出"最大流量 0.8L/min、进水 5℃、出水 38℃"这种指标时，必须同步给出对应的功率，否则采购按便宜的规格买回来，冬天直接冲不出来热水。我一般用一个几十行的脚本算，改参数就能出结果：

# 即热加热体功率估算：P = c * m * dT / eta C_WATER = 4.186 # 水的比热容, J/(g·C) FLOW_LPM = 0.8 # 目标流量, L/min T_IN = 5.0 # 进水温度, C T_OUT = 38.0 # 出水温度上限, C ETA = 0.90 # 加热体+流道热效率, 经验值 0.85~0.92 flow_gps = FLOW_LPM * 1000 / 60.0 # 换算成 g/s power = C_WATER * flow_gps * (T_OUT - T_IN) / ETA print(f"流量 {FLOW_LPM} L/min, 温升 {T_OUT - T_IN:.0f}C -> 需要 {power:.0f} W") # 流量 0.8 L/min, 温升 33C -> 需要 2046 W

逻辑说明：比热容乘以质量流量再乘以温差，得到每秒需要注入水的热量，除以热效率才是加热体必须输出的功率。参数说明：FLOW_LPM是喷淋最大档的实测流量，不是标称值；ETA同时包含加热体热损和流道散热，实测时用水温稳定后的输入功率反推更准；算出来的功率只是加热体规格，还要再往上留一档余量，因为市电跌落时可控硅导通角变小，实际输出会打折。按这个结果，0.8L/min 的机型配 2000W 级加热体是合理的，若想把流量提到 1.2L/min，功率需求会直接跳到 3000W 以上，那就要重新评估进线线径和漏电保护规格，这个判断必须在方案阶段做完。

2.4 安全条款写进方案，而不是留给测试去发现

行业里送检时对口的一般是 GB 4706.53 这类坐便器特殊要求，加上智能坐便器产品标准，方案文档里最好把安全设计逐条对应上，别等测试报告打回来再改。必须落到纸面的有：防干烧（水流开关信号与加热体温度上升斜率双重判断）、过温保护（硬件温控器与软件限温两级）、水温上限（一般不超过 40℃，儿童模式更低）、座圈温度上限与温升速率、漏电保护自检、儿童锁与误触锁。这些条目每条都要写明由哪个器件或哪段代码实现，方案评审时逐条勾掉。

提示：漏电保护、过温保护这类安全链路，要在方案里明确写成"独立于 MCU 的硬件通路"。只靠软件限温的方案，评审时基本会被打回。

3. 传感与执行链路的参数标定：落座检测、即热控温、喷嘴定位

3.1 落座检测：人体感应和落座感知不能混为一谈

翻盖用的人体感应和冲洗用的落座检测，是两件完全不同的事，方案文档里必须分开写。翻盖一般用微波雷达或红外，输出的是"附近有没有人"；冲洗前的落座检测用的是电容式薄膜、压力开关或者红外对管，输出的是"人是否坐在座圈上"。混用会出两种典型故障：人坐在马桶上看手机不动，雷达判断为无人，中途自动关盖；或者人只是路过，落座检测被误触发，机器直接开始喷水。

参数上我一般这样定：雷达感应距离设 0.3～1.2m 可调，出厂默认 0.8m；开盖延时 0.5～1s，关盖延时 60～180s 可调，默认 90s；落座检测用 20～50ms 的采样窗口做去抖，连续 N 次一致才认账。落座信号在固件里是一条"使能条件"，不是触发条件——只有落座为真、且水流压力在合规区间，冲洗按键才被允许响应。把这条逻辑写进方案，能省掉大量售后投诉。

3.2 即热式控温：功率前馈加 PID，参数怎么整

即热式控温的难点在于水量小、热容小，纯反馈调节永远慢半拍，出水温度会先冲高再回落。工程上的常规做法是功率前馈加 PID 修正：先按当前流量和目标温升算出基础功率，再用 PID 修正偏差。前馈部分的计算和第 2 章的功率公式是同一个，只是这里用实时流量计的读数。PID 部分我一般写成下面这种带限幅和抗积分饱和的结构：

typedef struct { float kp, ki, kd; float integral; /* 积分累加项 */ float last_err; /* 上一次偏差 */ float out_min, out_max; float integral_max; /* 抗积分饱和上限 */ } pid_t; float pid_calc(pid_t *p, float target, float actual, float dt) { float err = target - actual; p->integral += p->ki * err * dt; if (p->integral > p->integral_max) p->integral = p->integral_max; if (p->integral < -p->integral_max) p->integral = -p->integral_max; float d = p->kd * (err - p->last_err) / dt; p->last_err = err; float out = p->kp * err + p->integral + d; /* 输出: 可控硅目标占空比 0~100 */ if (out > p->out_max) out = p->out_max; if (out < p->out_min) out = p->out_min; return out; }

逻辑说明：误差进入比例项、积分项和微分项，输出直接映射到可控硅的导通占空比。参数说明：dt建议取 100ms，和过零检测的周期对齐；kp从一个较小的值起调，先让超调量控制在 2℃ 以内；ki决定稳态误差收敛速度，但水流量突变时最容易引发超调，所以必须做积分限幅；kd在即热系统里有意义，但它会放大 NTC 采样噪声，采样必须先用一阶低通滤波，滤波系数的经验值在 0.1～0.3 之间。

调参数的正确姿势是先在台架上跑水，用固定流量、固定进水温度标一轮，再做流量突变测试。如果每次出水都出现 3℃ 以上的过冲，问题通常不在 PID，而在前馈系数算错，或者可控硅驱动没有做过零同步，导致第一个半波就全导通。

3.3 喷嘴步进电机的零点校准与堵转判断

喷嘴的伸缩和往复摆动靠步进电机，方案文档里必须写明上电复位流程。常见做法是：上电后电机先向收缩方向多走一段行程，撞到机械限位或霍尔传感器后停止，把该位置记为零点，再按标定的步数伸到工作位。零点位置需要存进非易失存储，掉电重启时先用存储值快速定位，再校验一次霍尔信号，不一致就重新回零。

参数上一般这样设：单程行程 60～90 步（取决于螺距），往复幅度 15～25 步，往复周期 1～2s，堵转检测以连续若干步未收到霍尔跳变作为判据。堵转处理策略是停机加故障码上报，绝不反复重试——喷嘴卡住时电机持续通电，线圈温升很快，重试几次就可能烧驱动。下面这张表是我在方案里常用的传感器参数汇总，硬件和固件直接照着填寄存器。

3.4 烘干与除臭：风温闭环比风速更重要

烘干模块的体验差距，八成出在风温控制上而不是风速上。方案里常见做法是 PTC 加热配直流风机，PTC 自带一定的正温度系数特性，本身就是一层被动保护，但仍需要串一个温控器和软件闭环。闭环的被控量是出风口温度，控制量是风机 PWM 和 PTC 通断占空比，通常设 45～55℃，烘干时长 3～5 分钟，超时自动退出。

除臭模块分两类：活性炭或触媒这类被动吸附，方案里只需给出风路走向和更换周期；带 VOC 传感器的主动除臭，则需要写清传感器预热时间（一般几十秒）和触发阈值，否则刚上电就误触发，风机白转。我的做法是主动除臭默认关闭，把 VOC 读数只在 APP 上做展示，等传感器一致性和长期漂移验证通过之后，再在后续版本里打开自动触发。

4. 固件落地：状态机、非阻塞调度与故障码设计

4.1 主状态机：待机到烘干复位的十态划分

方案文档里如果只写"支持冲洗、烘干、除臭"，固件工程师就得自己猜状态怎么迁移。我在方案阶段就把状态机画成一张迁移表，固件照着写 switch 就行，测试照着设计用例。状态划分大致是：待机、感知、座圈加热、冲洗准备、冲洗、烘干、除臭、自检、故障、升级。每个状态写清进入条件、退出条件、超时时间，超时是最容易被漏掉的一栏，也是卡死类问题的主要来源。

对应的代码骨架并不复杂，关键是所有阻塞操作都不能放进状态处理函数里：

typedef enum { ST_IDLE = 0, ST_SENSE, ST_SEAT_HEAT, ST_WASH_PREP, ST_WASH, ST_DRY, ST_DEODOR, ST_SELFTEST, ST_FAULT, ST_OTA } state_t; static state_t g_state = ST_IDLE; static uint32_t g_state_tick = 0; /* 进入当前状态的时间戳, ms */ void fsm_run(uint32_t now_ms) { uint32_t elapsed = now_ms - g_state_tick; switch (g_state) { case ST_IDLE: if (seat_occupied() && key_wash_pressed()) fsm_switch(ST_WASH_PREP, now_ms); break; case ST_WASH_PREP: if (nozzle_at_target() && water_temp_ready()) fsm_switch(ST_WASH, now_ms); else if (elapsed > 5000) fsm_switch(ST_FAULT, now_ms); /* 5s 超时 */ break; case ST_WASH: if (elapsed >= wash_duration_ms()) fsm_switch(ST_DRY, now_ms); break; case ST_FAULT: heater_off(); pump_off(); fan_off(); /* 故障态一律断电 */ break; default: break; } }

逻辑说明：fsm_run在主循环里被周期调用，每次只做条件判断和状态切换，不做任何延时等待。参数说明：g_state_tick在fsm_switch里刷新，是超时判断的唯一依据；各状态的超时门限写成宏或配置表，不要硬编码在 case 里，方便按机型差异化配置。ST_FAULT里集中断电这一步，比散落在各个状态里可靠得多。

4.2 任务调度：把该在中断里做的事和不该做的分开

1ms 定时中断里只做三件事：喂看门狗、递增软件定时器、置位任务标志。ADC 采样、NTC 换算、状态机、通信全部放到主循环按节拍执行。我一般用一张任务表管理节拍，方案里给出这张表，固件工程师不用再讨论谁快谁慢：

typedef struct { void (*fn)(void); uint16_t period_ms; uint16_t cnt; } task_t; static task_t g_tasks[] = { { task_sample_sensor, 20, 0 }, /* 传感器采样 */ { task_heater_ctrl, 100, 0 }, /* PID 与可控硅输出 */ { task_fsm_run, 10, 0 }, /* 状态机推演 */ { task_comm_poll, 50, 0 }, /* 面板/遥控/模组通信 */ { task_self_check, 1000,0 }, /* 自检与故障汇总 */ }; void task_scheduler(uint32_t now_ms) /* 每 1ms 调用一次 */ { for (int i = 0; i < sizeof(g_tasks)/sizeof(g_tasks[0]); i++) { if (++g_tasks[i].cnt >= g_tasks[i].period_ms) { g_tasks[i].cnt = 0; g_tasks[i].fn(); } } }

逻辑说明：调度器本身极简，只负责按周期置位执行，任何任务内部都不允许长时间占用。参数说明：PID 放在 100ms 拍子上，是为了和过零检测的半波周期错开，避免同一时刻既采样又切换可控硅；task_self_check每秒汇总一次故障，比每个任务各自上报更好管理优先级。

4.3 故障码与日志：让售后一眼定位

方案文档里要给出一张故障码表，约定编码规则、是否锁机、是否可远程清除。经验做法是高位区分模块，低位区分具体原因，售后读一段十六进制就能定位到板子哪一路。常见条目包括座圈 NTC 开路短路、水温超限、流量不足、喷嘴堵转、风机堵转、通信超时、漏电自检失败。其中涉及加热和漏电的故障必须是锁机态，只能断电重启并记录次数，不能靠按键清除。

注意：故障日志建议写在带独立擦写寿命管理的区域，按"故障码 + 发生次数 + 最后一次发生时的关键温度与流量"三条记录，别只存一个码。售后拿不到上下文，只能整机返修。

4.4 OTA 与配网：分区、CRC 与自动回滚

带联网功能的机型，方案里要写清升级策略。常见做法是双分区 A/B 布局，新固件写入非运行分区，写入完成后校验 CRC 和版本号，校验通过再改引导标志，重启后运行新分区。新分区首次启动若在规定时间内未上报心跳，引导程序自动回滚到旧分区。配网流程则一般限定在 3 分钟内完成，超时退出并关闭模组射频，避免用户家里一堆同型号设备互相扫描。

构建和烧录环节，把命令写进方案附录能让交接少扯皮：

# 1. 配置并编译目标板固件 cmake -B build -DCMAKE_BUILD_TYPE=Release -DTARGET=toilet_main cmake --build build -j8 # 2. 打包含 CRC 与版本号的升级包 python3 tools/pack_fw.py --in build/app.bin --out build/app_pkg.bin --ver 1.2.3 # 3. 通过串口烧录并校验 stm32flash -w build/app_pkg.bin -v -g 0x08000000 /dev/ttyUSB0

逻辑说明：第一步产出可执行镜像，第二步在镜像尾部追加版本头与 CRC，第三步写入并做回读校验。参数说明：--ver必须单调递增，回滚判断依赖它；-v表示写入后校验，量产夹具上一定要开，开发阶段为了快可以关掉。烧录工具与目标芯片绑定，换 MCU 平台时这条命令要同步替换，方案里最好标注清楚依赖。

5. 用参数化脚本盯住水温曲线与座圈温升

方案文档写得再细，最后还是要靠数据验收。智能马桶最容易被投诉的两个指标是出水温度过冲和座圈温升太慢，这两个都只能靠连续采集曲线来判断，靠手感和单点读数看不出来。我一般让固件按 100ms 周期通过串口吐一行状态帧，上位机用一段脚本收下来存表，再画出曲线算超调量和稳态误差。

import serial, csv, time, re PAT = re.compile(r"T=(\d+),WT=([\d.]+),ST=([\d.]+),FLOW=([\d.]+)") ser = serial.Serial("/dev/ttyUSB0", 115200, timeout=1) with open("temp_log.csv", "w", newline="") as f: w = csv.writer(f) w.writerow(["t_ms", "water_c", "seat_c", "flow_lpm"]) t0 = time.time() while time.time() - t0 < 180: # 采集三分钟 line = ser.readline().decode("ascii", "ignore") m = PAT.search(line) if m: w.writerow([m.group(1), m.group(2), m.group(3), m.group(4)])

逻辑说明：脚本按行解析状态帧，把时间戳、水温、座温、流量四列写成 CSV，直接用表格软件出图或者丢给 matplotlib。参数说明：PAT里的字段顺序要和固件打印格式严格一致，改动打印格式时同步改正则，否则会静默丢数据；采样窗口建议覆盖"启动—稳态—关水"三个阶段，只看稳态段会漏掉最关键的过冲峰值。

验收时至少跑四组边界条件：进水温度最低、水压最低、连续冲洗三次、座圈从常温开始加热。水温超调量按经验应控制在 2℃ 以内，稳态误差 1℃ 以内；座圈从 20℃ 升到设定值的时间一般在 8～12 分钟，超过就要回头看加热丝功率和座圈保温层的设计，而不是先怀疑 PID。

还有一个能省大量时间的技巧：把 PID 参数和超时门限做成可在线修改的命令，通过串口或调试口下发，改完存到非易失存储。调试阶段不用反复烧录，一轮水温整定从半天压缩到一个小时。代价是方案里必须同步定义好这些调试命令的权限和出厂清除逻辑，量产前统一关闭写入口，别让现场能随便改安全相关参数。整定完成后，把最终参数连同当时的流量、进水温度、环境温度一起记进方案文档的版本记录里，换供应商或换加热体时才有对照基准，不至于每次都要从零调一遍。

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