一文轻松理解AUTOSAR之Watchdog协议栈(下)

汽车安全 1年前 (2023) admin

242 0 0

前言

首先，请问大家几个小小问题，你清楚：

AUTOSAR框架下的WdgM模块定义了哪几类监控模式吗？
每一种监控模式分别具备哪些特点呢？
使用WdgM模块时有哪些注意事项呢？

今天，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

正文

正如小T前文《一文轻松理解AUTOSAR之Watchdog协议栈(上)》所述，想必大家对Watchdog协议栈已经有了一个基本的认识与理解。那么顺着上文的思路，本文将针对Watchdog Manager模块中的如下三种监控模式做一个更为详细的理解，这三种监控模式可以理解为一种“软狗”，只不过该软狗的功能更为高级，不仅能够实现task是否卡死的这种异常情况，也能够实现软件运行逻辑，运行时长等方面的监控。

AUTOSAR中的WdgM模块(即Watchdog Manager)定义存在如下三种监控模式来完成上述功能：

Alive Supervision：用于监控周期性任务是否正常运行；
Deadline Supervision：用于监控非周期性任务某种监控实体(SE)运行时长是否满足设计要求；
Logic Supervision：用于监控软件运行逻辑是否符合设计需求，此类监控方式是功能安全ISO26262极力推荐的一种方式。

接下来将针对上述三种监控模式做进一步的理解，从各类监控模式的配置过程与算法逻辑两个方面进行展开分析，为后面实战奠定基础。

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调用函数周期的次数作为给到的监控参考周期；

算法逻辑

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

S1：监控实体SE为了发送一次Alive indication，那么该SE内部就需要调用一次函数WdgM_CheckpointReached，调用该函数的结果就是会使得该Checkpoint对应的Alive Counter+1；
S2：WdgM_Mainfunction函数调用周期由参数WdgMSupervisionCycle决定，而该Checkpoint对应的监控参考周期一般是WdgMSupervisionCycle的整数倍，即使用参数WdgMSupervisionReferenceCycle来进行设定；
S3：在监控参考周期内，许可的WdgM_CheckpointReached函数调用次数应该在[Expected值-WdgMMaxMargin，Expected值-WdgMMaxMargin]范围内，如果在实际监控过程中，WdgM_CheckpointReached函数调用次数超过了许可的范围，那么就说明在该对应的监控参考周期内，监控实体对应所在的任务执行过快或者出现未被成功执行到的情况，相应的会报出监控错误，即会影响到该SE的Local Status状态。
S4：为了避免出现有时间设定的WdgM_CheckpointReached函数调用次数为0或者1时，可能会出现即使该监控实体不再执行时，也会出现满足许可调用次数的情况，一般设计建议选取WdgM主函数周期及监控实体SE所在任务周期两者之间的最小公倍数来设置监控参考周期，确保每个监控参考周期内的WdgM_CheckpointReached()函数调用次数都是固定值，此时，上下偏差Min/Max Margin均设为0即可。

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经历的时间最大值；

如下图所示为某个SE实体同时存在多个Checkpoint的场景，在该类场景下，彼此之间不存在多大关联，仅在于相邻Checkpoint之间的执行时间的测量。

值得注意的是该类监控的SE中不同Checkpoint不能存在嵌套行为，如Start1, Start2, End2, End1 这种是不被允许的设计。

算法逻辑

S1：对于此类监控模式，必备两种Start Checkpoint以及End Checkpoint两大类，其中Start Checkpoint 通过参数WdgMDeadlineStartRef来进行设定，End Checkpoint通过WdgMDeadlineEndRef进行设定；
S2：对于该类监控，由于需要计算两个checkpoint之间的时间间隔，因此需要配置一个OS Counter；
S3：为了确定WdgM_CheckpointReached调用时的时间戳以及两个Checkpoint之间Transition的时间，那么调用的函数WdgM_CheckpointReached中需要使用os功能函数GetElapsedTime来计算两个Checkpoint之间的时间差距；
S4：通过S3步骤我们便得出两个Checkpoint之间Transition所经历的OS tick时间，并与配置的时间参数WdgMDeadlineMin以及WdgMDeadlineMax进行比较，若超限，则报出该监控实体Deadline Supervision错误，否则则正常。

Logic Supervision

对于Logic Supervison，作为ISO26262中极力推荐的一种程序流监控方式，用于检测程序代码执行逻辑是否正确再合适不过。

配置过程

对于每一个Logic Supervision，每个Checkpoint之间的Transition便组成了Graph，这些Graph便抽象出了代码逻辑的执行时序流，如下图所示为一个代码正常执行的程序时序流：

如上图我们可以知道我们将每个代码执行步骤分成了上面7个Checkpoint，其简化模型如下图所示：

在上图中清晰的描述了程序执行可能的路径，每个路径都通过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的一般运行算法：

S1：一旦程序实际执行过程中，运行至Checkpoint处，则调用WdgM_CheckpointReached()函数；
S2：在该函数体内会记录上一次的Checkpoint Id以及两个Checkpoint之间的Transition Id，其中Transition Id根据相邻两Checkpoint计算得到，若该Transition不属于配置的Transition Group，也就是说该相邻Checkpoint之间的Transition不属于预期Transition，那么就会报出该监控实体Logic Supervision的状态错误。

WdgM模式切换影响

对于WdgM模块切换状态的过程中，切换状态则是使用函数WdgM_SetMode来进行完成，模式切换会导致监控实体SE的监控参数变化。

因此有必要针对WdgM模块模式切换所造成的影响进行分析。

WdgM模块监控状态影响

如果当前Global Status为WDGM_GLOBAL_STATUS_OK或者WDGM_GLOBAL_STATUS_FAILED时，对于调用WdgM_SetMode的调用，每一个处于激活的SE的Local Status都应该保持不变；
如果当前Global Status为WDGM_GLOBAL_STATUS_OK或者WDGM_GLOBAL_STATUS_FAILED时，对于调用WdgM_SetMode之后处于Deactive的SE的local Status将会变成WDGM_LOCAL_STATUS_DEACTIVATED，同时也会设置对应的Alive，Deadline，以及Logic Supervision的状态为correct，同时也会清除错误计数器；
同时需要注意在WdgM的Global Status处于WDGM_GLOBAL_STATUS_OK或者WDGM_GLOBAL_STATUS_FAILED，WdgM_SetMode才允许被切换状态，否则就会对当前状态不会造成影响；

看门狗自身影响

在WdgM切换状态时，也需要考虑其对看门狗自身造成的影响，因为切换状态的过程中就伴随着关键看门狗参数的变化，底层则是通过调用WdgIf_SetMode来实现。

同时需要注意如果调用WdgIf_SetMode的返回值为Fail，表示当前的全局监控存在问题，且需要设置Global Status为WDGM_GLOBAL_STATUS_STOPPED，无论还是第一次看门狗超时复位还是立即复位，当然立即复位则取决于是否存在配置。

同时一般对于关键安全系统，看门狗一旦打开，不允许中途被关闭。

休眠模式看门狗处理流程

当EcuM模块的状态为Sleep状态时，此时CPU并没有断电，而是处于一种低功耗状态，在该状态下需调用WdgM函数接口WdgM_DeInit，同时应该设置一个特定的Trigger Condition，确保整个系统完成休眠剩余动作的过程中不被看门狗意外复位；

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

后期更多Watchodg实战内容，欢迎大家持续关注！