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

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

  • BSW的WatchDog功能-上
  • 一、先介绍几个概念
  • 二、3种监控类型流程图解析
    • 2.1 Alive Supervision
    • 2.2 Deadline Supervision
    • 2.3 Program Flow Supervision

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次代表正常,被通知其他次数为失败,通过分析此方案配置项可以满足上述需求。

AutoSAR配置与实践(深入篇)8.1 BSW的WatchDog功能(上)_第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为正常,其他次数为失败;
AutoSAR配置与实践(深入篇)8.1 BSW的WatchDog功能(上)_第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次为正常,其他次数为失败;

实现图如下:
AutoSAR配置与实践(深入篇)8.1 BSW的WatchDog功能(上)_第3张图片
方案三分析:可以比较贴切的满足需求中的监控场景。

Alive Supervision小结:

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

2.2 Deadline Supervision

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

设计缺陷:无缺陷,正确设计
AutoSAR配置与实践(深入篇)8.1 BSW的WatchDog功能(上)_第4张图片
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传出的检查点,必须等到最后的超时后才能报超时。
AutoSAR配置与实践(深入篇)8.1 BSW的WatchDog功能(上)_第5张图片

在上面这个例子,例子特点是都是依据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:几个传出转换中只有一个有截止日期的情况示例

设计缺陷:主函数之前到达了没有截止日期的检查点,则在最大截止日期过期后不会检测到任何截止日期违规
AutoSAR配置与实践(深入篇)8.1 BSW的WatchDog功能(上)_第6张图片

上面这个例子,需求具体为:
在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

AutoSAR配置与实践(深入篇)8.1 BSW的WatchDog功能(上)_第7张图片

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

你可能感兴趣的:(AutoSAR配置和实践,mcu,汇编,c语言,单片机,架构,网络协议)