WatchDog定义和设计原则
个人主页：云纳星辰怀自在
座右铭：“所谓坚持，就是觉得还有希望！”
1. 背景
软件运行过程中，如果进入某个循环无法退出，则会导致任务被block，譬如在AutoSar OS中，某个10ms任务卡死在某个循环，结果就是10ms任务包括比10ms任务优先级更低的20ms， 50ms等任务都被阻塞。这种情况，需要主动干预，或reset或重新上电。
基于上述背景，为提高软件稳定性和鲁棒性，引入看门狗概念：为了实现系统出现异常时能够自动完成系统复位操作保证整个功能的持续使用。
看门狗（Watchdog）在安全关键系统和非安全关键系统中的必要性：
1. 硬件与软件的不可靠性
- 硬件失效：电子元件老化、电源波动、物理损伤等硬件问题可能导致系统宕机或程序跑飞。看门狗通过定时复位机制，能够从底层恢复系统运行，避免硬件故障累积。
- 软件缺陷：即使经过严格测试，软件仍可能因边界条件、内存泄漏或并发问题进入死循环。看门狗作为最后一道防线，可强制重启系统，减少“僵尸进程”风险。
2. 恶劣环境的现实挑战
汽车电子：
- 电磁干扰（EMI）：发动机点火、高压线束等可能引发ECU（如ABS、ESP）程序异常。看门狗可快速恢复功能，避免高速行驶中因系统冻结导致事故。
- 温度极端：车载MCU在-40°C~85°C下工作，高温可能导致寄存器数据错误。看门狗能及时复位，防止错误状态持续。
工业与野外设备：沙漠、深海等场景的维护成本极高。看门狗可减少90%以上的非硬件损坏类故障，显著降低运维频率。
3. 成本与口碑的隐性价值
- 售后成本：一次现场维修的费用可能超过设备成本的10倍（如风力发电机停机维护）。看门狗的自动恢复能力直接节省人力、物流成本。
- 品牌信任度：用户对“死机”的容忍度极低。例如，车载信息娱乐系统频繁卡顿会导致用户投诉，即使不影响安全，也可能影响车企口碑。
4. 看门狗的技术实现层级
- 硬件看门狗：独立计时电路，不依赖CPU，抗干扰性强（如MAX6814芯片）。适用于对可靠性要求极高的系统（如安全气囊控制）。
- 软件看门狗：通过OS任务监控实现，灵活性高但依赖软件栈（如Linux的/dev/watchdog）。需注意“看门狗失效”问题（如监控任务本身卡死）。
- 分级看门狗：汽车功能安全标准ISO 26262推荐分层监控（如窗口看门狗+独立看门狗），覆盖从应用层到硬件的全栈错误。
2 看门狗本质
看门狗本质是一种定时器（Timer）。如果在规定的时间内没有"喂狗"（重置Timer），Timer就会溢出，当Timer溢出以后，执行用户自定义的一些异常处理动作，例如：重置系统。
针对被监视的目标设置一个计数器和一个阈值，watchdog会自己增加计数值，并等待被监视的目标周期性地重置计数值。一旦目标发生错误，没来得及重置计数值，watchdog会检测到计数值溢出，并采取恢复措施（通常情况下是重启）。
2.1 定时器分类
Table 5 定时器分类
| ID |
类型 |
优势 |
缺陷 |
| 1 |
软件定时器 |
可以多个并存，资源限制小 |
易受负载影响，稳定性差 |
| 2 |
硬件定时器 |
精度高、响应快，不受负载影响 |
存在资源限制 |
软件看门狗的时间本质上也需要依赖硬件外设上的硬件定时器。
3 看门狗分类
- 按照相对uC位置：内部看门狗和外部看门狗（硬狗）；
- 按照软件实现方式：软件看门狗和硬件看门狗；
- 按照功能：功能看门狗和窗口看门狗。
内狗和外狗关系，示意如下：
内狗、外狗、硬狗、软狗关系，示意如下：
3.1 外部看门狗
外部看门狗一般而言，都是硬件狗。对嵌入式软件开发而言，外部看门狗一般采用中断触发方式喂狗。原因如下：
- 软件方式易受程序负载影响而不能及时喂狗，如果外狗的"喂狗"窗口期很短，容易造成误复位。
所以，外狗一般采用中断方式喂狗。
中断程序优先级高，进入中断例程以后，不能无判断直接执行"喂狗"动作，而是需要有条件地执行"喂狗"，例如：判断喂狗条件是否满足。比如：Task#n Counter是否在有效范围内，如果在就喂狗，如果不再就执行异常处理动作（系统复位）。
3.2 内部看门狗
控制MCU的内部看门狗定时器。它提供触发功能和模式选择服务。Wdg模块是直接访问相关硬件寄存器。主要监控程序运行后的软件状态，如监控OS启动后，周期性Task、非周期性Task、软件时序的运行状态。需要注意就是，内部watchdog存在程序初始化和程序shutdown的监控盲区。因为看门狗的主要作用是监控软件系统的运行状态，如果看门狗的任务优先级太低，那么可能会被其他任务阻塞（While(1)卡死），导致看门狗无法及时发现系统故障（无法设置异常条件，不能触发系统复位），从而影响系统的稳定性和可靠性。
一般来说，内部软件看门狗的任务优先级应该设置得比其他常规任务高。但是，它的任务优先级又不能高于系统关键性任务（刹车程序任务等safety相关）。所以，看门狗的任务优先级在兼顾有效监控程序的同时，也需要确保关键任务的正常运行。
--如果喂狗（软件看门狗）动作在中断程序中，当程序卡死以后，定时器溢出，进入中断程序，是否还需要喂狗？--此时不应该无条件喂狗，应该识别喂狗条件是否满足。由于程序卡死，因此也就很难满足喂狗条件。所以，即使程序进入了中断例程，也不应喂狗，而是进行异常处理（eg：复位系统）。
3.3 内外狗监控盲区问题
内部watchdog存在程序初始化和程序shutdown存在监控盲区，所以外部wdg可以fix这部分问题。如果uC没有及时喂外狗，导致外狗超时，同时拉低ROT Pin，也就是拉低uC的Reset Pin，触发uC的复位。参考上图。注意：外狗一旦被外部使能，一般不会关闭 。
如果软件只是开启了内狗，eg：仅使能 Alive Supervision。需要等到OS启动以后，内狗功能才发挥作用。但是，在程序的初始阶 段，OS启动之前，如果程序异常跑飞，内狗则无法起到监控作用。如下图所示：
在AUTOSAR架构下，ECU的启动流程由EcuM模块管理，分为以下几个阶段：
- Startup Phase（启动阶段）：初始化硬件、启动OS。
- Run Phase（运行阶段）：OS启动后，执行周期性任务（如喂狗）。
- Shutdown Phase（关闭阶段）：ECU休眠或复位。
内部看门狗（Internal WDT）仅能在OS启动后生效（如Alive Supervision监控周期性任务）。OS启动前（如Bootloader、EcuM初始化阶段），若程序跑飞，内部看门狗无法监控，导致系统无法复位。根本原因：
1.内部看门狗依赖
- 需OS调度喂狗任务（如WdgM_MainFunction），而OS启动前无任务调度机制
- 部分MCU的内狗默认关闭，需软件显式开启（如STM32的IWDG），但初始化阶段可能未完成
2.监控盲区
- 启动阶段（EcuM_Init → OS启动）：硬件初始化、时钟配置等关键操作无监控。
- 关闭阶段（OS终止 → 断电）：若程序卡死（如while(1)），内狗已关闭，无法触发复位
解决方案：
1.启用外部看门狗（External WDT）
- 作用：独立于MCU，覆盖启动/关闭阶段的监控盲区。
- 实现方式
- 上电即启动：在EcuM_Init中尽早使能外部看门狗（如通过GPIO或SPI配置）。
- 喂狗机制：
启动阶段：由Bootloader或EcuM_AL_DriverInit函数喂狗。
运行阶段：由OS任务（如WdgM_MainFunction）喂狗。
关闭阶段：在EcuM_Shutdown中延迟关闭外狗，确保安全下电。
- 推荐器件：ASIL-D级：TLF35584（集成于PMIC，支持窗口/功能看门狗）。低成本方案：TPS3823（独立硬件看门狗，QM级）。
2.内部看门狗优化
- 延迟使能：在OS启动后（EcuM_StartupTwo）再开启内狗，避免初始化阶段误触发。
- 超时时间调整：启动阶段设较长超时（如500ms），运行阶段缩短（如100ms）
3.内外双狗协作
| 阶段 |
外部看门狗 |
内部看门狗 |
| 启动阶段 |
监控硬件初始化 |
未启用 |
| OS运行阶段 |
备份监控 |
主监控（Alive/Deadline） |
| 关闭阶段 |
监控下电流程 |
已关闭 |
3.4 硬件看门狗
工作原理：
- 独立硬件定时器：由专用硬件电路（如MCU内置或外置看门狗芯片）实现，不依赖CPU运行。
- 软件仅需“喂狗”：软件需在超时（Timeout）前定期“踢狗”（Reset Timer），否则硬件自动触发系统复位。
- 不受软件崩溃影响：即使CPU死机、程序跑飞，硬件定时器仍会独立计时并强制复位。
3.5 软件看门狗
工作原理：
- 基于软件定时器：利用CPU的通用定时器（如SysTick）或操作系统（如RTOS任务监控）实现。
- 完全由软件控制：需软件主动更新定时器计数值（喂狗），若主程序卡死，看门狗也可能失效。
- 可分层监控：可监控多个任务/线程，比硬件看门狗更灵活。
| 分类 |
优势 |
劣势 |
| 硬件Wdg |
✅高可靠性：不受软件错误（如死循环、内存溢出）影响，适合安全关键系统（如汽车ECU、医疗设备）。 ✅低延迟复位：硬件直接控制复位信号，响应速度快（通常<100ms）。 ✅抗干扰性强：电磁干扰（EMI）或电源波动不易导致看门狗失效。 |
❌灵活性低：超时时间通常固定或有限可调（如STM32的IWDG仅支持几档预分频）。 ❌依赖硬件支持：需MCU内置或外置看门狗电路，增加BOM成本（但通常仅需几分钱）。 |
| 软件Wdg |
✅高度灵活：可自定义超时时间、监控策略（如任务级看门狗）。 ✅低成本：无需额外硬件，仅依赖现有CPU资源。 ✅支持复杂逻辑：可结合系统状态判断是否复位（如仅重启特定任务而非整个系统）。 |
❌可靠性较低：若看门狗任务本身卡死（如优先级反转、内存泄漏），则失效。 ❌依赖CPU运行：若CPU死锁或电源异常，软件看门狗无法生效。 ❌响应延迟：需经过软件逻辑判断，复位速度较慢（可能数百ms）。 |
4 硬件看门狗设计原则
硬件看门狗是保障系统可靠性的关键组件，其设计需遵循以下核心原则，以确保安全性、鲁棒性、可维护性和兼容性：
4.1 可靠性优先原则
1.独立于主系统运行
- 硬件独立计时：看门狗应由独立时钟源（如RC振荡器）驱动，不依赖主CPU时钟，避免因时钟失效导致看门狗失效。
- 最小化软件依赖：喂狗操作（如GPIO翻转）应尽量简单，避免复杂协议（如I²C/SPI）引入额外风险。
2. 抗干扰设计
- 电源隔离：看门狗供电应与主系统分离（如采用LDO稳压），防止电源噪声导致误触发。
- 信号滤波：喂狗信号（如GPIO）需增加RC滤波或施密特触发器，抑制毛刺干扰。
4.2 安全关键系统强制原则
1.不可关闭性（Locked Mode）
- 硬件锁定：一旦启用，看门狗必须无法通过软件关闭（如熔丝位/OTP配置），仅允许硬件复位或断电禁用。示例：汽车MCU（如NXP S32K）需写密钥才能禁用看门狗，且密钥仅在调试模式有效。
- 防篡改设计：禁止通过寄存器篡改超时时间或喂狗逻辑。
2.失效安全（Fail-Safe）
- 默认复位：若喂狗失败，看门狗必须强制系统复位，而非仅记录日志。
- 看门狗自检：上电时自动检测看门狗功能是否正常（如STM32的窗口看门狗自检模式）。
4.3 超时时间设计原则
1. 匹配系统最坏执行时间（WCET）
- 公式：Timeout ≥ 1.5 × WCET（留出冗余应对初始化延迟或临时阻塞）。示例：汽车ECU任务周期为100ms，看门狗超时可设为150~200ms。
- 动态调整（可选）：在低功耗模式下延长超时时间（如从100ms调整为1s）。
2. 避免误触发
- 初始化阶段延迟使能：系统上电后，先完成关键硬件（时钟、内存）初始化，再启动看门狗。
- 喂狗任务优先级最高：在RTOS中，喂狗任务需设为不可阻塞的最高优先级。（Safety相关除外）
4.4 喂狗（Kick）机制设计原则
1.简单可靠的喂狗方式
- GPIO优先：通过单一引脚电平翻转或脉冲喂狗，硬件资源占用少且抗干扰。
- 优化：使用硬件定时器自动生成喂狗脉冲，减少软件依赖。
- 避免复杂协议：禁用I²C/SPI喂狗，除非系统无GPIO资源。
2. 喂狗逻辑容错
- 多重校验：喂狗前检查系统关键状态（如堆栈、任务存活），异常时不喂狗以触发复位。
- 心跳监测：结合软件看门狗分层监控，确保喂狗任务本身不被阻塞。
4.5 默认状态与调试支持原则
1. 默认关狗（Power-On Disabled）
- 上电默认关闭：多数MCU（如STM32）的硬件看门狗默认关闭，需软件显式启用。
- 例外处理：若芯片默认开狗（如某些汽车MCU），需在Bootloader中立即喂狗或硬件关狗。
2.调试接口设计
- 物理关狗手段：预留测试引脚（如拉低GPIO强制关狗），用于刷机或在线调试。
- 安全与便利平衡：在开发阶段允许临时关闭看门狗，量产时通过熔丝位锁定。
4.6 兼容性与扩展性原则
1.多核系统支持
- 指定单一核心喂狗：避免多核竞争导致喂狗冲突。
- 全局监控：若多核共享看门狗，需确保任一核故障均能触发复位。
2.分层监控（Layered Watchdog）
- 硬件看门狗：作为最后防线，监控整个系统。
- 软件看门狗：监控应用任务，实现细粒度恢复（如仅重启故障线程）。
4.7 验证与测试原则
1.超时时间测试
- 注入人为延迟，验证看门狗能否在设定时间内准确复位。
2.抗干扰测试
- 施加电源波动、EMI干扰，确保看门狗不误触发或失效。
3.失效模式分析（FMEA）
- 分析看门狗自身失效的影响（如时钟停振、喂狗信号断路），并设计冗余方案。
5 软件升级中喂狗
这里主要是考虑软件升级过程中，如何"喂"外部硬件看门狗。一般来说，工程上常见的外部硬件看门狗触发原理如下：
如果uC没有在规定时间内有效喂狗，外部硬件看门狗（eg：SBC中的硬件狗）就会主动拉低ROT Pin脚，Reset uC。所以，在升级的过程中，进入Bootloader程序以后，需要关闭SBC中的外部看门狗，避免程序升级过程中，喂狗不及时导致的刷写失败。但是，一些SBC中，外狗一旦使能，不能关闭。这样的情形时，Bootloader程序需要及时喂狗，避免喂狗不及时导致的刷写失败。
刷写过程中，哪些动作会导致喂狗超时呢？答：比如，Application程序更新以后，使用非对称算法对Application进行验签，这样的动作比较耗时，很可能超过喂狗的窗口期。
后续系列围绕AutoSar WatchDog Stack定义和ISOLAR配置为主题展开，感兴趣请关注！
参考文章
承上
tbd
启下
CSDN
