AUTOSAR配置与实践（深入篇）8.2 BSW的WatchDog功能-窗口狗
- 一、为什么使用窗口狗（Window Watchdog）
- 二、窗口狗初始化和喂狗流程概要
- 三、Wdg配置项详解
- 四、窗口狗详细流程
一、为什么使用窗口狗（Window Watchdog）
窗口狗作用概括一下:
主要是针对普通喂狗中的缺陷，如误操作寄存器非法喂狗，或者跑飞后又恢复，普通狗不能有效检测到这些异常。
而窗口狗可以多数情况检测到如上异常，一定程度提高的系统防错能力。
关于窗口狗和普通狗两者区别，下面用几张图展示，相信看过后比较容易理解了。
场景一：
场景一分析：
系统运行正常，任务正常周期喂狗
场景二：*
场景二分析：
系统异常（如软件跑飞），但是应用误操作Wdg寄存器，系统仍然可以正常运行.普通狗无法检测到这种非法喂狗场景。
场景三：
场景三分析：
注意
-
窗口狗是以中断形式喂狗的，且要求喂狗时机需满足一定窗口（如图示例为总超时周期的75%-100%）;
-
当系统运行异常时（如软件跑飞），但是应用仍能误操作Wdg寄存器，窗口狗模式下，检测到在无效窗口喂狗，判定为错误，采取错误处理（如复位）。
-
窗口狗可以检测到非法喂狗场景, 并执行有效防护。
二、窗口狗初始化和喂狗流程概要
- Wdg初始化：Main函数中调用Wdg_<>_ init函数，（因可能有多个Wdg，<>为用户自定义名称）
在Wdg_<>_ init内做如下几项操作：
-
调用<>_Wdg_init，初始化寄存器配置，使默认超时、75%中断喂狗、默认Fast/Slow模式（超时action、喂狗窗口）等配置生效，此时看门狗已启动。
-
调用 <>_ Wdg_ SetTriggerCondition，重置默认超时计数N，考虑初始化耗时一般默认超时设置较长。
-
调用<>_Wdta_Trigger 首次喂狗(可选)。
-
加载快/慢狗模式：Main函数中调用EcuM_Init函数，使用WdgIf_SetMode完成Wdg模式设置(Fast/Slow)。
完成对应设置后同时启动OS。
注：设置时机也可在OS启动后由WdgM_Main设置，有的ECU在 Wdg_init初始化后就不再允许设置SetMode。 -
计数重置:OS启动后，一方面WdgM主函数周期调用WdgIf_SetTriggerCondition重置喂狗计数WdgCnt，之后循环重置（喂狗计数计算方法参考下文配置项讲解小结介绍）；
-
中断喂狗： 另一方面Wdg_6_Wdta1_Rb_ServiceWDTA 周期性中断喂狗。
- 在中断内管理喂狗计数，每次递减1。
- 发现计数不为0，则在中断内喂狗。
- 发现喂狗计数为0，停止喂狗，等待WdgM复位。
此时表示异常，WgM可能被其他任务堵塞而没有及时重置计数，
三、Wdg配置项详解
是否使用75%中断（Watchdog 75% ISR）：是否使用75%的对应模式(Fast/Slow)超时时间作为中断喂狗时间，wdg_init使用
初始模式（WatchDog default init mode）:初始模式(Fast/Slow)，wdg_init使用
初始超时时间（Initial Timeout）：默认超时时间, wdg_init使用。
本例设置500ms
FastMode超时时间(Timeout in fast mode)：在FastMode 下的超时时间。
本例设置34 ms。
Wdg检测到错误后响应(watchdog error detection reaction)：触发复位或者进入NMI中断。注：这里的错误指的可能是非窗口期喂狗，也可能是没有喂狗导致了超时。
本例配置复位。
中断喂狗周期(Service Interval)：中断喂狗的周期。在中断里会做两件事，一、检查是否喂狗计数是否0，若非0则喂狗，若为0则触发错误响应。
本例配置26ms
设定依据:由于FastMode超时为34ms，75%中断为26ms。
喂狗窗口（window open period）:所允许的喂狗时间窗。
本例为25%，即中断有效喂狗窗口为Fast(Slow) Mode超时的75%-100 %，即喂狗窗口25.5 ms -34ms，结合如上中断喂狗周期26ms，喂狗周期位于窗口期内。
用户超时时间（WdgMTrigger Time）：用户期待的超时，决定了最终的超时时间从而进行超时动作（如复位）
本例为75 ms ，触发狗选择的模式是快狗模式。
喂狗计数计算方法：
WdgCnt= WdgMTrigger Time/ Service Interval +1, 即喂狗计数 = 用户超时/喂狗周期。
喂狗和超时判定大致的机制为：
- 轮询重置计数：wdgM轮询重置WdgCnt
- 轮询消耗计数：中断喂狗定期消耗WdgCnt， 检查未消耗完毕则保持喂狗，当中断喂狗时发现WdgCnt消耗完毕，停止喂狗触发超时
本例中，Trigger Count =75/26 + 1 = 3;，即喂狗计数为3次，喂狗周期26ms，即从wdgm调度异常不能重置计数开始，经历3个中断周期：总检测时间= 3 *26= 78ms。大致和我们的需求（75ms）相符。
四、窗口狗详细流程
1.看门狗初始化：系统启动后进行看门狗的初始化，初始化流程参考前述<流程概要>
本例默认fastmode，超时时间500ms，中断喂狗时间26ms，初始喂狗计数WdgCnt =500/26+1=20次
2.周期重置计数：OS开始调度后，会根据用户超时在WdgM_MainFunction重设看门狗，周期性重置。
本例用户超时时间75ms，重置喂狗计数WdgCnt =75/26+1=3
3.周期喂狗：75%中断产生，中断内发现喂狗计数不为0，触发喂狗操作，并且消耗1次喂狗计数。此后每次中断内都会进行相同操作。
本例喂狗计数N=3，消耗后N-1=2；
4-5：正常喂狗：系统正在正常运作中，喂狗计数在正常的重置和消耗中。
6. 系统调度异常，WdgM_MainFcuntion调度丢失（可能被其他任务抢占或者系统跑飞），无法重置Wdg计数N。
7.计数持续消耗:随着喂狗中断产生，喂狗计数仍在不断消耗(丢失重置源，计数不再重置新增)。
8.等待超时：超时后的第三个中断内，发现喂狗计数为0，检测到了异常，所以停止喂狗，等到超时
9.执行超时Action。WdgM判断超时触发超时Action响应
本例Action响应设置为复位，所以触发复位操作。
