看门狗该在什么条件下喂？用任务健康检查和故障注入验收RTOS固件

看门狗应在产品健康策略所要求的证据仍然有效时才被喂。任务进入循环、定时中断继续触发，或网络还能回复ping，都可能与关键业务停滞同时发生。设计必须定义进展、喂狗权限和安全恢复。以下是待验证的架构与验收方法，以Zephyr 3.7.0作版本化参考，不代表已经完成固件实测。

把看门狗目标写成具体业务失效

列出要检测的失效：关键任务不再完成工作、外设等待超出边界、健康监督者卡住，或调度停止。同时写出机制不能证明的内容。软件可能持续运行却计算错误，因此仅凭进展的看门狗不是正确性证明，必要时还需要合理性检查或独立保护。将未覆盖因素写出来，才能判断其他机制该承担什么责任。

每类失效都应说明检测过晚、误复位和复位后仍未恢复的后果，并规定复位期间与启动早期的输出状态。对加热器、阀门或电机控制器而言，重启不自动等于安全。检测与恢复预算来自产品运行约束，不能从演示程序复制一个秒数，再把所有任务硬套进去。

按任务阶段定义健康证据

健康检查点应对应已经完成的阶段，例如采样通过校验、处理周期结束或输出更新提交。任务报告递增序号与已完成阶段，监控者依据该阶段的截止期检查。重复发布旧序号，或者仅报告进入一个永远不返回的操作，不应刷新健康证据。

事件任务无新数据也可能完全健康，但应明确定义合法空闲状态，而不是永久豁免。睡眠、Flash操作、启动和升级需要各自审核过的预算与退出条件。还要验证计数回绕、低功耗时钟行为，以及并发读取进展字段是否得到一致快照。

设计健康汇总和喂狗权限

明确谁有喂狗权限。在应用自管架构中，工作任务发布进展，由一个监督者检查当前所有必需任务，再决定是否喂硬件狗。关键记录过期时，其他任务仍活跃也不能替它获得授权。生产者心跳同样不能充当消费者已经完成处理的证据。哪些任务在当前模式下必需，应是明确的配置和状态。

审查全部可喂狗、禁用、重配和重启看门狗的路径。无条件定时器或中断喂狗，可能让主控制任务已经卡死的系统一直存活。维护模式也要有受限入口和明确退出。监督者读取快照时，不能无限等待它正要监控的同一把锁；监督者自己停止后，硬件兜底仍应按声明触发恢复。

区分任务监控与硬件兜底

软件任务监控可以在内核仍运行时指出哪个受监督通道停止进展；硬件超时则为软件监控无法执行的情况提供另一层保护。覆盖范围取决于时钟独立性、复位路由、低功耗行为及硬件是否真正启用。若两层依赖同一个失效资源，实际独立性可能比方框图看起来弱。

Zephyr 3.7.0 task watchdog基于内核定时器，可管理多个通道并选择硬件看门狗作为兜底，但这不证明每块板都支持全部超时或回调。应检查初始化结果，并按对应版本的watchdog API核对驱动能力。图中的应用监督者是概念方案，不是Zephyr内部实现图，不能把两种架构混用而忽略实际责任。

先隔离还是立即复位

按故障类别规定反应。非关键传感器失败时，产品允许的情况下可有界重置驱动并降级；必需控制功能丢失时，可能需要先进入安全输出，再复位。关键任务仍不健康却继续喂狗，必须有明确批准的降级模式和限制，不能只因为恢复循环还在运行就视为健康。

最小诊断记录只在安全且时间有界时尝试，不要等待完整日志落盘而阻塞恢复。有些故障连最后一笔记录都写不了，因此平时进展更重要。还要定义连续启动失败策略，防止不断重启时反复启用危险输出，或重放结果未知命令。受限恢复模式需要进入条件，也需要经授权返回正常模式的路径。

建立故障与预期反应一一对应的矩阵

在隔离目标与安全负载上使用可控注入入口。每个故障规定触发方法、预期检测、允许降级时间、隔离或复位动作，以及必须留存的证据。一个很有价值的测试是让关键任务停更，但低优先级健康或日志任务仍运行，它可以暴露“系统还有活动就喂狗”的设计漏洞。

锁等待不自动等于优先级反转，诊断仍需要拥有者与调度证据。停止调度或屏蔽中断等试验必须遵循平台限制。发布构建要移除或禁用测试钩子，并留下核查记录，不能把注入接口变成长期后门。

同时验收漏报误报和恢复后功能

异常与正常两类测试都要做：故障注入检查漏报，合法峰值负载检查误复位。覆盖最长允许启动、升级、睡眠与外设恢复路径，考虑时钟容差、调度延迟，以及适用时的硬件喂狗窗口。故障到检测、安全动作、复位和首次正确业务恢复，应分别计时，不能混成一个“恢复时间”。

报告硬件、构建、配置、持续时间、重复次数与未覆盖条件。选定测试通过不等于覆盖所有故障，更不等于安全认证。结合复位证据保留提高可诊断性，并把规则写入固件验收要求。实际评审可向Obeita提供任务截止期、硬件看门狗能力、安全状态要求和允许的故障注入环境。