五千字长文讲解AUTOSAR WatchDog机制

fl8111

本文来源：AUTOSAR_BSW05_看门狗_七千字长文讲解WatchDog机制

学东西要深入，也不必过于深入，要不AUTOSAR为什么会有分层的概念呢？其目的就是为了让大家工作量减轻啊！但是，你可以不用，但是很多东西不能不懂，要不出现问题的时候由于不清楚逻辑，会导致你解决问题的效率变得非常低下。

因此建议大家学习一点概念性质的内容，补充自己的知识短板！

看门狗机制。看门狗想必大家应该都再熟悉不过了吧?隶属于功能安全机制的一种，是控制器非常重要的保护机制。在设备无人值守的情况下系统出现异常时能够自动完成系统复位操作保证整个功能的持续使用。看门狗功能对于关键安全系统是必须的，对于非关键安全系统也是很有必要的。

这篇文章将从以下几个方面来做些看门狗的介绍，看完想必你对AUTOSAR看门狗的实现逻辑会有一些基本的认识：

AUTOSAR架构下的看门狗是怎么样的，涉及哪几个模块？

AUTOSAR提供了哪几种监控机制？

AUTOSAR协议跳转状态机？

三种机制的详细介绍？

休眠模式下如何处理WDT？

对于看门狗的机制还是简单解释下：

大白话说，就是控制器养了一条小狗，这条狗必须隔一段时间就喂口饭，如果不喂，它就反过来咬你，让你程序reset重新开始执行。

最早引入Watchdog是在单片机系统中，由于单片机的工作环境容易受到外界磁场的干扰，导致程序“跑飞”，造成整个系统无法正常工作，因此，引入了一个“看门狗”，对单片机的运行状态进行实时监测，针对运行故障做一些保护处理。

当然这篇文章的目的，不是讲解什么是看门狗，那是嵌入式控制器本身的概念，我暂时没兴趣。我们要聊的是，AUTOSAR架构下，看门狗模块是怎么实现的。
1 AUTOSAR架构下的看门狗涉及哪几个模块？

如下图所示：

WdgM: 为应用层提供安全相关的服务

WdgIf: 看门狗接口，主要功能是触发硬件看门狗

Wdg Drv: Mcal中看门狗的驱动

一般来说，对于上述三个模块，其中整个Watchdog协议栈最为关键的部分就是WdgM模块，由于其存在十分重要的监控类别，监控对象按照AUTOSAR概念将其称为Supervised Entities，俗称"监控实体"。

它是实现WDG模块功能的核心模块，其有如下的作用：

1.提供用户操作的API。

2.判断各Supervision Entity的Local Status，汇总得到整个WDG的Global Status。

3.提供故障处理和喂狗。

4.下发指令给下层WdgIf，并获取其反馈结果。

当然 我们可以通过针对不同的应用场景，独立的设置不同的监控机制，完成整个软件执行过程中偶发的异常状态。
2 AUTOSAR提供了哪几种监控机制？

Watchdog Manager模块的监控类别，可以将其分为如下三种：

Alive Supervision：用于需要监控周期性任务调度周期是否稳定的场景；Deadline Supervision：用于需要监控非周期性任务某段代码区间执行时间是否在预期内的场景；Logical Supervision：用于需要监控程序执行顺序是否符合代码设计的场景。

听不太明白？大白话版：

Alive Supervision：要求10ms一次的任务，100ms是不是跑了10次？Deadline Supervision：单次任务按预计1ms完成，你用了多久跑完的？；Logical Supervision：我要求任务执行先甲再乙后丙方，你是不是按照顺序执行的？

典型的对于一个监控实体就是一个SWC或者一个runnable，它们在其内部存在一个或者多个Checkpoint来完成彼此之间的Transition，这种迁移变化就被称为Graph，接下来我们将更为细致的分析下上述三种监控方式的特点。

Alive Supervision : 用于检查某一个监控实体是否执行时间过快或过慢，通过参数设定固定一个时间段，检查下期望调用Checkpoint函数的次数是否在预期设定的阈值范围，如果在范围内则监控结果为correct，否则监控结果则为incorrect；Deadline Supervision：检查两个checkpoint之间执行时间是否在设置的阈值范围内，如果在范围内则监控结果为correct，否则监控结果则为incorrect，其中最为关键的两个参数就是监控阈值的最小值与最大值；Logical Supervision : 检查程序的执行的时序是否在预期的设定范围内，本质上来讲就是看这些checkpoint之间的Transition是否在预期的Transition列表中，如果在列表中则监控结果为correct，否则监控结果则为incorrect。

WdgM模块能够及时处理多个监控实体的多个监控类别以及多个看门狗，正因如此，因为需要针对每一个监控实体都需要通过唯一的状态进行表示，我们将其称为Local Status，每一个监控实体均有唯一的Local Status来进行表示，其状态可以分为监控OK，监控失败，监控超时，如下图2是AUTOSAR标准文档中的监控实体的Local Status状态机图。当然，以上三种机制都是可以单独用的，即在同一个软件版本内可以并行支持，也可以只用到其中的一种机制。3 Watchdog监控状态机介绍

无论使用哪种监控机制：WdgM模块能够及时处理多个监控实体的多个监控类别以及多个看门狗，正因如此，因为需要针对每一个监控实体都需要通过唯一的状态进行表示，我们将其称为Local Status，每一个监控实体均有唯一的Local Status来进行表示，其状态可以分为监控OK，监控失败，监控超时，如下图2是AUTOSAR标准文档中的监控实体的Local Status状态机图。


每一个监控实体均存在唯一的Local Status状态机，所有监控实体的最终状态最终会进行一个汇总，该汇总的状态就被称为Global Status。你看，local、golbal ；从本地到全局，很好理解；对于Global Status的状态机如下图3所示：


每个监控实体均会存在唯一的Local Status与之对应；但是Global Status则针对WdgM模块总体监控状态而言仅有一个。

上述每一个监控实体的Local Status变化如何导致最终Global Status的变化，则是通过在WdgM_Mainfuntion中进行周期性的检查，为了获得每个监控实体的最终状态，WdgM模块需要针对的三种监控模式的结果进行检查，确定好Local Status之后才能够最终确定最终的Global Status。

如下图4所示为每个监控实体的三种监控方式的结果将会最终在Wdg_Mainfunction中进行统一的计算处理，最终得到整个WdgM的Global Status的状态。



local -Global 状态的传递过程

这里有个误区： local status的状态，不是单个机制的结果体现，而是这个SE多个机制实行结果的综合体现；

通过上面的讲解，大家是应该明白了啥是SE 啥是本地状态，啥是全局状态了；

接下来将针对上述三种监控模式做进一步的理解，从各类监控模式的配置过程与算法逻辑两个方面进行展开分析。
4 AUTOSAR三种机制的详细介绍？

4.1 Alive Supervision

周期性监督实体在给定的时间跨度内对它们的执行次数有限制。通过Alive Supervision,看门狗经理定期检查被监督实体的检查点是 否已达到给定的限制。这意味着看门狗管理器检查监督实体是否运行得不太频繁或不太罕见要提供实时监视,需要配置检查点及其时间约束。活动监督最简单的配置是一个检查点,没有任何转换。Alive Supervision最为简单的一种监控方式，如下图可以看到对于监控实体SE3中仅有一个Checkpoint3-1，同时也需要注意对于使用Alive Supervision的SE的Checkpoint不会考虑其Checkpoint之间的转化。


如果需要配置某SE的Alive Supervision，需要配置下如下四个基本参数：

WdgMExpectedAliveIndications：在给定的时间内某监控实体SE调用WdgM_CheckpointReached函数的次数，即Expected值；

WdgMMaxMargin：实际调用上述函数的次数的增加的偏移值，即实际值=Expected值+WdgMMaxMargin；

WdgMMinMargin：实际调用上述函数的次数的减少的偏移值，即实际值=Expected值-WdgMMaxMargin；

WdgMSupervisionReferenceCycle：基于WdgM_Mainfunction调用函数周期的次数作为给到的监控参考周期；

alive supervision的大体工作流程：

基于上述配置的参数，我们便可以梳理出某监控实体SE的Alive Supervision监控算法逻辑：

监控实体SE为了发送一次Alive indication，那么该SE内部就需要调用一次函数WdgM_CheckpointReached，调用该函数的结果就是会使得该Checkpoint对应的Alive Counter+1；

WdgM_Mainfunction函数调用周期由参数WdgMSupervisionCycle决定，而该Checkpoint对应的监控参考周期一般是WdgMSupervisionCycle的整数倍，即使用参数WdgMSupervisionReferenceCycle来进行设定；

在监控参考周期内，许可的WdgM_CheckpointReached函数调用次数应该在**[Expected值-WdgMMaxMargin，Expected值-WdgMMaxMargin]**范围内，如果在实际监控过程中，WdgM_CheckpointReached函数调用次数超过了许可的范围，那么就说明在该对应的监控参考周期内，监控实体对应所在的任务执行过快或者出现未被成功执行到的情况，相应的会报出监控错误，即会影响到该SE的Local Status状态。

为了避免出现有时间设定的WdgM_CheckpointReached函数调用次数为0或者1时，可能会出现即使该监控实体不再执行时，也会出现满足许可调用次数的情况，一般设计建议选取WdgM主函数周期及监控实体SE所在任务周期两者之间的最小公倍数来设置监控参考周期，确保每个监控参考周期内的WdgM_CheckpointReached()函数调用次数都是固定值，此时，上下偏差Min/Max Margin均设为0即可。
4.2 Deadline Supervision

如前文所述，Deadline supervison主要用于非周期性的监控实体SE，该类监控实体往往都是事件型进行触发，触发之后的监控实体SE执行的时间不能过长，同时也不能过短，这个SE的执行时长就需要通过相应的阈值进行限定，从而来监控其运行状态是否满足设计要求。

配置过程：对于每一个SE的Deadline Supervision，两个Checkpoint时必须需要进行配置的，因为Deadline Supervision就是针对两个Checkpoint之间的Transition执行时间进行监控，即针对监控实体SE执行的动态行为进行监控。

如下图所示为最为简单的某SE的Deadline Supervision监控方式，存在一个Start Checkpoint4-1以及End Checkpoint4-2，两者之间无需形成闭环，但是一个Start Checkpoint与一个End Checkpoint对于采用Deadline Supervision的SE是必不可少的。

基本参数如下：

WdgMDeadlineMin：两个Checkpoint的Transition经历的时间最小值；

WdgMDeadlineMax：两个Checkpoint的Transition经历的时间最大值。

算法逻辑

对于此类监控模式，必备两种Start Checkpoint以及End Checkpoint两大类，其中Start Checkpoint 通过参数WdgMDeadlineStartRef来进行设定，End Checkpoint通过WdgMDeadlineEndRef进行设定；对于该类监控，由于需要计算两个checkpoint之间的时间间隔，因此需要配置一个OS Counter；为了确定WdgM_CheckpointReached调用时的时间错以及两个Checkpoint之间Transition的时间，那么调用的函数WdgM_CheckpointReached中需要使用os功能函数GetElapsedTime来计算两个Checkpoint之间的时间差距；

通过S3步骤我们便得出两个Checkpoint之间Transition所经历的OS tick时间，并与配置的时间参数WdgMDeadlineMin以及WdgMDeadlineMax进行比较，若超限，则报出该监控实体Deadline Supervision错误，否则则正常。4.3 Logic Supervision

对于Logic Supervison，作为ISO26262中极力推荐的一种程序流监控方式，用于检测程序代码执行逻辑是否正确再合适不过。（推荐是推荐，真正能够配好可以说非常难！！）

有些代码是要有严格的执行顺序的，比如ADC数据采集电压，那肯定要先成功采集到电压，再把电压传递给别的模块才能是最新的数据。

这个不展开举例了，官方文档上有举例，直接拿来用。有一段代码假设如下，问你要怎么设计去监控它是按逻辑顺序执行的

i = 0;
while(i < n)
{
         if (a < b)
           a = b;
         else
           a = 0;
         i++;
}

//先思考一下，怎么设计？



官方文档给的答案很简单粗暴，近乎是每一行设置个打卡点，然后设置好先后顺序。如上图。假设代码里识别到CP0-5，就会判断上一次的CP点是不是CP0-3或者CP0-4，如果不是那就算发生异常了，记录一次异常，逻辑图如下



在上图中清晰的描述了程序执行可能的路径，每个路径都通过Checkpoint来进行设定，那么便得到了上面所有的可能性，这些Checkpoint的Transition关系需要在配置中进行体现。除此以外，还需要特别介绍两个基本概念，一个是Internal Graph以及External Graph：

Internal Graph: 若所有的Checkpoint均属于一个SE，那么这些Checkpoint的Transition就组成了这个Internal Graph，即一个SE只允许存在0个或者1个Internal Graph；

External Graph: 若至少存在两个Checkpoint属于不同的监控实体SE，那么这两个Checkpoit之间的Transition便组成了External Graph。

这两类Graph的显著区别在于Internal Graph不会受到WdgM 模式切换影响，但是External Graph则会受到WdgM模式切换的影响。

每一个Internal Transition连接两个Checkpoint，这就意味着所有的模式共享同样的Internal Transition，当在某种WdgM模式中进行抑制监控实体SE时，那么便可以使得Internal Transition的Logical Supervision进行失效。

具体功能执行流程：

根据上述图中的程序流执行抽象，我们可以得出Logic Supervision的一般运行算法：
一旦程序实际执行过程中，运行至Checkpoint处，则调用**WdgM_CheckpointReached()**函数；在该函数体内会记录上一次的Checkpoint Id以及两个Checkpoint之间的Transition Id，其中Transition Id根据相邻两Checkpoint计算得到，若该Transition不属于配置的Transition Group，也就是说该相邻Checkpoint之间的Transition不属于预期Transition，那么就会报出该监控实体Logic Supervision的状态错误。
注意：！！！一般对于关键安全系统，看门狗一旦打开，不允许中途被关闭。
5 休眠模式下如何处理WDT？

一个特定的Trigger Condition，确保整个系统完成休眠剩余动作的过程中不被看门狗意外复位；因此，无论是EcuM模块状态变成Sleep或者OFF状态，都应该特别关注完成整个系统Sleep或者OFF之前看门狗应保证不被意外复位，如通过延长长窗口或者在完成剩余动作的过程中进行喂狗。

以上内容均为理论性的分析内容，

实际项目上的配置，大家可以参考大佬文章:

AUTOSAR实战篇：手把手带你搞定Watchdog协议栈_autosar wdgif-CSDN博客

好了，以上差不多就是全部内容；感谢观看，我是一片绿叶，如果对您有帮助别忘了给我点个小赞~(●ˇ∀ˇ●)

6 参考文献

[1] AUTOSAR_SWS_WDG;
[2] AUTOSAR实战篇：手把手带你搞定Watchdog协议栈_autosar wdgif-CSDN博客

[3] 一文轻松理解AUTOSAR之Watchdog协议栈(下)_autosar配置与实践(深入篇)8.2 bsw的watchdog功能-窗口狗-CSDN博客

---

本文作者：一片绿叶，欢迎关注作者的知乎，创作不易，欢迎点赞再看收藏关注！

汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车从业人员。