AutoSAR配置与实践（深入篇）8.1 BSW的WatchDog功能（上）

BSW的WatchDog功能-上

->返回总目录<-

此前3.6章节 , 3.7章节内容主要介绍了Wdg架构和外部主要交互,不清楚的可以先回头看下。本章节将从原理上介绍三个监控类型Alive/ Deadline/ Program Flow三种监控类型，并针对每种类型配以时序图和详细解释，相信此文后能对WatchDog主要功能有个全面的了解，后续在Wdg实践篇我们将针对本章节的例子对实际的配置和实现进行讲解。

一、先介绍几个概念

监督实体(SE)：受监管实体是由WdgM监控的软件部分。可以代表一个算法、一个函数，或者在操作系统的情况下一个完整的任务。监督实体可以分布在多个任务或应用程序中，同一任务也可以有多个监督实体。

检查点(Checkpoint)：标志着算法执行过程中的重要步骤。在检查点，受监督的实体直接调用函数WdgM_CheckpointReached()，告知WdgM某处逻辑执行到了， WdgM以此判断，被监控实体在某段时间内执行次数是否符合预期（Alive监控），或执行执行时间是否超出预期（Deadline监控），又或者执行顺序不对（Flow Control Status）。如果不符合预期，WdgM判定违例并通知应用采取措施。

二、3种监控类型流程图解析

2.1 Alive Supervision

从需求实现上介绍这个监控类型

需求： 假设WdgM监控周期是20ms，被监控的Task周期是30ms，我们想在20ms内监控Task的执行次数情况。

实现分析：由于监控时间窗>被监控的Task周期，所以在监控时间内，Task可能不被执行到，或者被执行1次；

方案一：配置项设定：

WdgMExpectedAliveIndications = 1
WdgMMinMargin=1
WdgMMaxMargin=0
WdgMSupervisionReferenceCycle=1
WdgMSupervisionCycle：1

由此前的配置项含义讲解，可得知：

监控时间 = WdgMSupervisionCycle*cycle =20ms，即在20ms内实施监控.
期待被CP触发通知的次数:
WdgMExpectedAliveIndications - WdgMMinMargin ~ WdgMExpectedAliveIndications +WdgMMaxMargin,即0~1次。

即在20ms监控时间内，应用被通知的Alive次数为0或1次代表正常，被通知其他次数为失败，通过分析此方案配置项可以满足上述需求。

方案一分析：此方案满足了需求，但是考虑如果任务停止执行情况，应用将一直不会被通知，而配置项决定了允许通知次数是（0 ~ 1次），即一直不被通知也是能接受！
所以这种实现方案没有考虑应用停止允许的情况，并不友好。

方案二、配置项设定

Expected Alive Indications = 2
Min Margin = 1
Max Margin = 0
Supervision Reference Cycle = 2

由此前的配置项含义讲解，可得知：
监控时间 = 40ms，
期望被CP触发的次数下限= 1，
期望被CP触发的次数上限= 2。
即在40ms监控时间内，应用被通知的Alive次数为1或2为正常，其他次数为失败；

方案二分析：相比方案一检测到了任务停止运行情况，但是考虑这种情况，如果在上图左侧，应该被通知2次的时候，实际被通知了一次（少通知一次），这种错误能检测到吗
这种错误场景，按照当前的规则（被通知1-2次表示 ok）也是可以接受的，所以无法检测到这种错误。
因此方案二可以进一步优化。

方案三：

实现分析：将监督参考周期设置为WdgM监督周期和任务周期的最小公倍数。在上面给出的例子中，这将是60ms(三个WdgM监督周期)。在这种情况下，我们期望正好有2个Alive通知。因此，最小和最大边距都是0。

配置项设定：
WdgMExpectedAliveIndications = 2
WdgMMinMargin=0
WdgMMaxMargin=0
WdgMSupervisionReferenceCycle=3

由此前的配置项含义讲解，可得知：
监控时间 = 60ms，
期待被通知的次数下限= 2，
期待被通知的次数上限= 2。
即在60ms监控时间内，被应用通知Alive 2次为正常，其他次数为失败；

实现图如下：

方案三分析：可以比较贴切的满足需求中的监控场景。

Alive Supervision小结：

Alive 类型的方案配置原则：将监督参考周期设置为WdgM监督周期和任务周期的最小公倍数（如方案三）。

2.2 Deadline Supervision

Case 1 ：带有截止日期的简单监督实体示例

设计缺陷：无缺陷，正确设计

SE: 被监控实体
CP：在应用SWC中设置的被监控点，用于监控SWC是否按预期执行。
被监控点通过WdgM_CheckpointReacheds函数设置。

在上面这个例子中， 第一个截止时间定义的0 ~ 2s，因此在CP0执行之后，CP1需要在0 ~2s时间段被执行到。
第二个截止时间1~3s，意味着在CP1执行之后，CP2需要在1 ~3s的时间段被执行，否则将检测到违反截止期限。
此时Wdg会用WdgM_LocalStateChangeCbk函数通知应用SWC错误状态。

以下来看几种设计存在缺陷的例子

Case 2： 多个带截止日期的传出转换示例

设计缺陷：所有从CP0传出的检查点，必须等到最后的超时后才能报超时。

在上面这个例子，例子特点是都是依据CP0为开始时间的！具体为：

• 在CP0执行之后，CP1需要在0 ~2s时间的窗口被执行到。
• 在CP0执行之后，CP2需要在3 ~5s时间的窗口被执行到。
• 在CP0执行之后，CP3需要在2 ~4s时间的窗口被执行到。

注意：

• 如果没有到达下一个检查点，则WdgM_MainFunction()仅在所有传出转换的最大截止日期已过之后才检测截止日期违反
• 因都是以CP0为起始计算时间.即如果执行CP0之后卡住，则在到达CP0后不早于5秒执行的下一个主函数中检测到截止日期违规

设计优化：修改参考点，不要都从一个CP传出。比如CP2可以参考CP1设定Deadline，CP3可以参考CP2。

Case 3：几个传出转换中只有一个有截止日期的情况示例

设计缺陷：主函数之前到达了没有截止日期的检查点，则在最大截止日期过期后不会检测到任何截止日期违规

上面这个例子，需求具体为：
在CP0执行之后，CP2需要在0 ~1s时间的窗口被执行到（ CP1的被执行到的时间窗没有限制）。

实现分析：

• 如果在CP0之后没有达到CP1、CP2，那么下一个WdgM_MainFunction()(在达到CP0后至少2秒执行)检测到违反了截止日期。
• 但是如果在2秒后到达CP1，但在下一个WdgM_MainFunction()之前，则不会检测到违反截止日期的情况
• 上述例子我们期待CP2执行，但是CP1执行的情况下反而不会检测

设计优化：为了避免这种模棱两可的情况，最好的做法是为检查点的所有传出转换定义最后期限(或者一个都不定义)

Deadline Supervision小结：

Deadline 类型的方案配置原则：为检查点的所有传出转换定义最后期限，并且尽量不从一个CP传出（如Case 1）。

2.3 Program Flow Supervision

• 监督实体temperature_control有6个检查点；
• 在检查点read_temperature之后，有可能到达检查点temperature_needs_correction；
• 在检查点read_temperature之后到达检查点heater_adjusted_successfully会违反程序流程。