一、安全基石：医疗设备为什么需要看门狗？
各位工程师朋友，咱们今天聊个硬核话题——看门狗。说白了，它就是嵌入式系统里那个「盯着你干活、发现你死机就踹你一脚」的保安。
我入行那会儿，有个老前辈跟我说过一句话，至今记忆犹新：「没有看门狗的医疗设备，就像没有安全带的赛车。」 当时我还不太理解，直到后来亲身经历了一次事故复盘……嗯，咱们慢慢聊。
1.1 看门狗的本质：一个简单的「心跳检测器」
看门狗（Watchdog Timer，WDT）本质上就是一个计数器。它不停地倒计时，如果主程序在规定时间内没有「喂狗」（重置计数器），它就认为系统挂了，然后强制复位。
你想想看，这玩意儿多简单？但就是这么个简单的东西，在医疗设备里却是保命的底线。
核心逻辑：
- 主程序正常运行 → 定期喂狗 → 计数器重置 → 系统稳定
- 主程序死机/跑飞 → 没人喂狗 → 计数器归零 → 系统复位
我在项目中遇到过一种情况：有些工程师觉得看门狗「太粗暴」，复位会丢失数据，于是把喂狗周期设得特别长，甚至干脆关掉。这种做法，说白了就是在玩火。
1.2 IEC 62304 标准：不是建议，是强制要求
IEC 62304 是医疗设备软件的生命周期标准。它对系统监控的要求，可不是「建议你装一个」，而是「不装就别想过认证」。
咱们来看看具体条款：
| 条款编号 | 要求内容 | 我的解读 |
|---|---|---|
| 5.2.6 | 软件单元必须包含错误检测机制 | 看门狗是最基础的错误检测手段 |
| 5.5.3 | 系统必须能检测并响应致命错误 | 死机属于致命错误，必须能恢复 |
| 8.2.1 | 安全机制必须经过验证 | 光装了不行，还得证明它有效 |
| 9.6.1 | 软件变更后需回归测试安全功能 | 改一行代码，看门狗测试得重做 |
我建议各位在项目初期就把看门狗纳入架构设计，而不是等到测试阶段才想起来。为什么？因为后期加看门狗，往往要改整个喂狗逻辑，牵一发动全身。
1.3 真实案例：输液泵药物过量事故复盘
2015年，美国FDA收到一份严重事故报告——某品牌输液泵在输注过程中突然失控，持续泵入药物，导致患者药物过量。调查结果让人唏嘘：看门狗失效。
咱们来复盘一下事故链条：
- 初始故障：主控芯片受到电磁干扰，程序指针跑飞
- 看门狗本该动作：但喂狗代码恰好位于一个「死循环」之后
- 致命后果：程序一直在死循环里转，喂狗代码永远执行不到
- 系统无响应：看门狗超时，但复位电路设计有缺陷，复位信号没生效
- 灾难发生：电机持续运转，药物过量输注
⚠️ 教训总结：
- 喂狗代码不能放在「可能被跳过的路径」上
- 看门狗复位电路必须独立于主控芯片
- 电磁兼容性（EMC）测试不能省，尤其是辐射抗扰度
我曾经参与过一个类似的事故分析。那台设备的问题更隐蔽——喂狗代码放在中断服务程序里。表面上看没问题，但当中断被意外屏蔽时，看门狗就形同虚设了。
1.4 避坑指南：我踩过的三个坑
做医疗嵌入式这么多年，我在看门狗上栽过跟头。分享出来，希望大家别重蹈覆辙。
坑一：喂狗周期太宽松
我曾经把看门狗超时时间设为10秒，觉得「够用就行」。结果有一次系统卡在某个外设等待上，足足卡了8秒才恢复。虽然没死机，但8秒的「盲区」在医疗设备里是致命的。后来我改成500ms，配合多级看门狗策略。
坑二：喂狗代码太集中
有些同事喜欢在main函数末尾统一喂狗。这其实很危险——如果前面的某个函数死锁了，喂狗代码根本执行不到。我现在的做法是：在每个关键任务执行完后都喂一次狗，形成「分布式喂狗」。
坑三：忽视看门狗自身的可靠性
看门狗也是芯片，也会坏。我见过一个案例，看门狗芯片的复位输出引脚虚焊，导致复位信号时有时无。从那以后，我要求硬件团队在原理图上标注「看门狗复位信号必须用示波器实测验证」。
1.5 总结：看门狗不是万能的，但没有看门狗是万万不能的
说了这么多，其实就一句话：看门狗是医疗设备安全的第一道防线，但绝不是最后一道。
它解决的是「系统死机」这个单一故障模式。对于更复杂的故障——比如传感器漂移、算法错误、通信异常——还需要其他安全机制来兜底。这些内容，咱们后面的章节会逐一展开。
最后留个思考题：如果你的设备在看门狗复位后，需要恢复之前的运行状态，你会怎么设计「复位后恢复逻辑」？这个问题的答案，直接关系到设备的安全等级评定。
好，这一章就到这儿。下一章咱们聊聊「多级看门狗架构」——如何在单芯片方案里实现分层监控。到时候见。