AUTOSAR实战篇：手把手带你搞定Watchdog协议栈

AUTOSAR实战篇：手把手带你搞定Watchdog协议栈

前言

小T出品，必是精品！ 手把手搞定Watchdog协议栈，你值得拥有!

---

正文

在进行Watchdog协议栈实战之前，建议先阅读小T之前有关Watchdog协议栈的两篇文章《Watchdog协议栈上》与《Watchdog协议栈下》先了解下在AUTOSAR框架下的Watchdog协议栈到底存在哪些概念与内容，有哪些需要注意的点。

为了便于大家针对实战内容的理解，小T将之前协议栈的基础内容介绍在本文中做个总体的介绍与总结，方便大家抓住重点，快速完成实战配置的理解。

Watchdog协议栈总体介绍

本文以AUTOSAR标准4.2.2为例，如下图1所示，整个Watchdog协议栈可以分为如下三个主要的模块：

图1 Watchdog协议栈总览

• WdgM模块：全称“Watchdog Manager”，首先它是一项BSW Service, 该Service提供的就是从硬件看门狗实体监控的过程抽象出来完成软件程序执行监控抽象；
• WdgIf模块：全称“Watchdog Interface”，它属于ECU抽象层，能够允许上层WdgM模块来同时处理多个看门狗实体，比如外部看门狗或者内部看门狗等；
• Wdg模块：全称“Watchdog Driver”，它属于MCAL的一部分，用于完成看门狗初始化，模式设置以及喂狗设置等。

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

我们可以通过针对不同的应用场景需要设置不同的监控类别，从而完成整个软件执行过程中偶发的异常状态。

Watchdog监控类别

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

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

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

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

Watchdog协议栈状态机

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

图2 监控实体Local Status状态机

正因为每一个监控实体均存在唯一的Local Status状态机，所有监控实体的最终状态也需要进行唯一的确定表示，该状态就被称为Global Status，对于Global Status的状态机如下图3所示：

图3 WdgM模块Global Status状态机

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

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

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

图4 WdgM模块Global Status计算过程

本文将通过示例工程来进行配置某个监控实体的两种监控方式，一种是Alive Supervision，另外一种则是Deadline Supervision，该两类涉及的checkpoint顾名思义则存在3个。

• 1个用于Alive Supervision的监控；
• 2个用于Deadline Supervision的监控；

对于Alive Supervision，一个10ms的runnable将会被创建用于作为一个监控实体，在其内部将会调用checkpoint函数，每一次调用checkpoint函数就是一次indication，WdgM模块将通过1s周期的时间跨度上检查是否存在100次Indication，上下的周期波动设置称5；

对于Deadline Supervision，同样的runnable将会被使用，在某些特殊场景下，如特定can信号的接收处理可以设置下deadline Supervision来进行监控；

针对Logical Supervsion，配置方法上与上述两种方式没有太大差别，可以依葫芦画瓢来实现相关的配置。

以下就是上述需求的具体实现过程，整个配置实战讲解过程可以分为8个基本步骤，一起跟着小T手把手练习下，保证能够让你快速掌握整个Watchdog协议栈的配置实战并应用于具体的客户项目中：

S1: WdgM模块配置

本文将以ETAS工具为例给大家讲解整个Watchdog协议栈配置过程。

首先基于Bsw Service模块创建一个全新的WdgM模块：

相关的重要配置参数如下表所示：

以下是本次示例工程的具体配置如下图所示：

在统一Container下面定义监控实体(Supervised Entities), 本文仅定义一个监控实体，该监控实体内部定义三个新的Checkpoint。

如下几个参数设置需要注意：

• WdgMEcucPartitionRef：EcuC Partition仅仅在partition在使用的过程中才需要用到，如果没有用到可以不用设置；
• WdgMInternalCheckpointInitialRef：对于采用监控实体的初始节点；
• WdgMInternalCheckpointFinalRef：对于监控实体的结束节点；
• **WdgMOSCounter：**用于Deadline Monitoring的监控实体的超时时间计算；

最后，对于WdgMWatchdog暂时不要设置任何Reference，后面会讲到：

现在切换至WdgMConfigSet container，然后创建一个新的WdgMMode配置，并设置WdgMexpiredSupervisionycleTol，同时WdgMSupervisionCycle 就是WdgM_MainFunction的运行周期。

然后创建一个新的WdgMAliveSupervision，设置需要检车的Checkpoint以及期望的indication次数（WdgmExpectedAliveIndications），并设置好对应的阈值容差范围(WdgMMaxMargin and WdgMMinMargin)，以及用于监控的时间区段，本项目设置的是1s，由于上图中设置的Wdg_Mainfunction周期为10ms，因此WdgMSupervisionReferenceCycle设置成100，即表示监控时段为1s。

以上述同样的方式来完成WdgMDeadlineSupervision的设置，通过设置参数(WdgMDeadlineMax and WdgMdeadlineMin)来完成对应阈值的设定，同时索引开始节点与结束节点。

每一个WdgMMode 至少需要索引一个监控实体，索引所在的位置位于WdgMMode下的一个sub-container WdgMLocalStatusParamss来完成，通过设置WdgMlocalStatusSupervisedEntityRef来完成监控实体的引用，同时还要针对失败的Alive Supervision次数进行设定，通过该参数WdgMfailedAliveSupervisionRefCycleTol的设定便可以决定该监控实体什么时候可以进入到Expired状态。

最后在WdgMMode内部创建一个新的WdgTrigger，该container用于设置每次调用SetTriggerCondition函数进行喂狗的时间间隔，通过设置参数WdgMTriggerConditionValue来决定，单位为ms，然后选择WdgMWatchDogMode来设定喂狗的模式，该模式在正常状态下一般设置成FAST模式，然后设置参数WdgMWatchdog来索引在WdgMGeneral创建的Watchdog。

S2: Wdg模块配置

接下来我们来创建Wdg模块，首先跟之前创建WdgM模块类似的方式创建Wdg模块，如下图所示

这个模块本来应该属于MCAL中的一部分，因此需要作为索引来实现整个在ETAS工程中的配置，同时需确保相关的配置参数与MCAL实际配置的保持一致；

S3: WdgIf模块配置

接下来我们来配置WdgIf模块，该模块的创建于Wdg模块类似，如下图所示：

首先配置WdgIfGeneral模块：

然后配置WdgIfDevices，在当前case中仅存在一个Watchdog，因此仅需reference之前的一个Wdg即可，当然如果存在多个Watchdog，那么需要多创建一个Watchdog Driver模块，以便在WdgIfDevice中可以进行添加。

现在WdgIfDevice已经被创建，因此回到之前的WdgM模块，在WatchdogDeviceRef中设置对应的索引，如下图：

S4: OS配置

由于Deadline Monitoring需要使用到Os Counter作为计数，因此需要打开OS模块配置一个新的counter用于计数，当然也可以直接使用已经存在的OS tick：

然后返回到WdgMSupervisedEntity中配置，并设置对应的OS Counter 索引：

S5：EcuM模块配置

由于WdgM，Wdg，MCU模块需要在ECU启动的过程中进行初始化，因此针对Watchdog协议栈的初始化设定如下：

S6: BswM模块配置

对于WdgM De initialization需要在BswM模块中创建一个Action：

然后将该Action添加至BswM Action List ：”BswM_AL_Shutdown“:

至此，你便可以通过添加新增模块WdgM与WdgIf模块，便可以完成BSW的生成：

最后一件需要做的事情就是需要修改Watchdog的集成代码，特别需要关注WdgM_Bsw_User.c以及WdgM_Bsw_User.c着两个文件，在当前用例中仅完成Deadline Monitoring的定义，对于Alive Supervision的函数定义则是通过RTE接口来实现，后续文章会展开说明：

S7：相关SWC模块更新

当上述BSW代码成功生成之后，WdgM服务模块将会提供出一些服务接口给到我们的SWC层进行使用。

首先，在一个已经存在的WdgSWC中可以添加一个新的runnable，该runnable可以被时间事件激活。

接下来添加下面三类Port口：

• 为Alive Supervision添加可以设置checkpoint的RPort接口，该Port Interface类型为WdgM_LocalSupervision；
• 添加一个RPort用于读取监控实体的Local Status，使用的Port Interface是WdgM_LocalMode；
• 添加一个RPort用于读取监控实体的Global Status，使用的Port Interface是WdgM_GlobalMode；

然后，设置相关的Service Call Point，该Service Call Port必须进行创建：

最后添加该SWC对应的mapping Type Maps用于wdg协议栈的新模式：

S8：系统配置更新

新的Component需要被添加进system，因此需要将这些新添加的component 添加进对应的ECU中,如果已经存在则无需添加：

一旦Map成功之后，然后便可以通过RTE Editor方式打开system，将新的runnable Map至对应的OS Task中。

接下来就是创建WdgM PPort 与对应的需要被监控的SWC的RPort进行连接：

最后更新下ECU extract然后重新生成RTE以及OS两个模块，便可以最终完成整个Alive Supervision的监控。

值得注意的是关于本文中提到的Deadline Monitoring监控未走RTE，则需要手动调用WdgM_Bsw_User.h中的两个函数根据需求进行自行监控，对于Alive Supervision监控如果不想走RTE，也可以在WdgM_Bsw_User.h以及WdgM_Bsw_User.c两个文件中进行定义声明。

更多精彩实战内容推荐如下，欢迎大家多多关注支持，小T将后续继续增加更多精彩的实战文章，帮助大家一起学习进步！

更多精彩内容，敬请关"ADAS与ECU之吾见"！