企业官网建设流程全解析

喂狗
在嵌入式程序中，看门狗是用来监测一旦发生错误就向芯片发出重启信号的电路，防止程序跑飞，也可以防止程序在线运行时出现死循环。AutoSar的看门狗功能中，喂狗即Trigger Watchdog，当触发看门狗后，计时counter会被刷新重新开始计算，通过判断喂狗的时机或间隔来判断程序是否在正常运行。
内狗/外狗
Wdg通常有两种：一种是芯片内部自带的片内看门狗，另一种是在芯片外部通过SPI这种接口连接的片外看门狗。

内狗：MCAL只负责常用的有MCU内部看门狗，片内看门狗的特点是Wdg模块是直接访问相关硬件寄存器。
外狗：片外看门狗属于板级设备抽象层负责，通常需要使用MCAL提供的其他模块（比如SPI，DIO,PWM等）来访问/控制外扩看门狗芯片。这种不能直接访问硬件寄存器。
由于其特殊性，该模块的代码除了可以在ROM里面运行外，也可能会在RAM里面运行。比如在Bootloader刷写Flash时，Wdg模块可能作为二进制文件里面的一部分在RAM上运行。

1.3 超时狗/窗口狗
按喂狗时机又能将看门狗分为超时狗（Timeout Wdg）和窗口狗(Window Wdg)。

1.3.1 超时狗
超时狗喂狗很简单，即采用Timeout模式计时，在Timeout时间内都可以喂狗，当检测到超过设定的Timeout时间仍未喂狗则会触发进一步安全保护措施。

1.3.2 窗口狗
窗口狗需要在某个特定的窗口周期在open window内才能喂狗，在窗口期外喂狗都无效，例如下图中在(0.72-1.2)*twD范围内喂狗有效。
.Wdg架构
在AutoSar架构中，作为功能安全中至关重要的一个功能，看门狗系统架构相对简单，如下图：

服务层有WdogM（Wdog Manager）模块，主要为软件状态机，通过软件策略来实现一些监测功能，对上可汇报当前错误状态，对下可调用抽象层接口进行一系列不同类型的复位操作。ECU抽象层则有WdogIf模块，主要将各种看门狗模块进行抽象化管理。MCAL层则就是各种类型看门狗的WdgDriver了。
4.相关模块

5.WdgM功能简介
WdgM 是 AUTOSAR 基础软件架构中的一个标准的软件模块，属于服务层（service layer）。它主要用于监控应用程序执行的可靠性，包括监控程序运行的周期和程序运行逻辑的正确性。
WdgM可配置一定数量的SE。当它检测到违反了对程序执行的配置时间和/或逻辑约束时，它将采取许多可配置的操作来从此故障中恢复。
WdgM 主要提供以下功能：
1. 监控位于 MCU 内的多个独立的应用程序，它们可以拥有独立的时序要求；
2. 对功能安全相关的任务和周期性功能（main function），进行逻辑流监控；
3. 每个 SE 可以具备单独的错误反应机制；
4. 根据 ECU 的状态和硬件的能力，支持看门狗的 Off\Slow\Fast 模式。

5.1 WdgM喂狗机制
在将WdgM喂狗机制之前先从上到下（层）说一下这里面涉及到的几个时间参数：

Condition Value：由WdgM刷新的Timeout，在该时间内wdg不应被reset,也可以称为用户超时时间；
WdgM_MainFunction的调度周期：在WdgM状态机正常的情况下，会周期性地刷新Condition Value；
Wdg ResetTime ：看门狗硬件复位的时间，也就是硬件寄存器从startvalue到溢出的时间；
Refresh Time ：即 GPT定时中断中喂狗的时间（wdg中配置）
WdgM 负责刷新喂狗条件，在WdgM_MainFunction中会刷新Condition Value（配置值），并通过WdgIf_SetTriggerCondition让WdgDriver重置硬件寄存器（喂狗），并会计算出中断喂狗的counter = Condition Value / Wdg ResetTime， 之后如果WdgM_MainFunction不再刷新Condition Value，则会在中断中进行counter喂狗，并且counter-1。 因此，如果 WdgM监测的SE出现问题，则无法刷新Condition Value，则Condition Value会自减至 0，进而引起看门狗复位。
Condition Value的存在，使得 WdgM 可以更灵活的控制看门狗的复位时间，从决定复位到真正复位，可以留给用户更充分的准备时间。
WdogM提供三种监测机制，分别是Alive Supervision， Deadline Supervision，Logical Supervision。

5.1.1 Alive Supervision
Alive Supervision 主要用来监控某个 SE 运行的周期是否正确。其基本原理是：在待监控的 SE 中设置 CP，在固定时间内，监测该 CP 到达的次数。基本实现方式就是一开始需要用户配置一个上限值和下限值，在一个统计周期内，WdogM会计算出这个SE的运行次数，如果运行次数超出这个区间，则Alive 检测失败，否则 Alive 检测成功。
Alive Supervision 中的CP都有自己的参数（期望区间和监测周期），且SE可以有多个CP,但是不推荐；
当然每个Mode下的Alive Supervision可以是不同的（取决于配置）；

使用 Alive Supervision 有如下限制：
1. 同一 CP 不能隶属于多个 Alive Supervision；
2. Alive Supervision 监控到错误后，其 SE 的本地状态将首先切换至 FAILED ，并且 错 误 计 数 增 加 ， 如 果 Alive 错 误 计 数 超 过WdgMFailedAliveSupervisionRefCycleTol，则状态切换为 EXPIRED；
3. Alive Supervision 监控正确，其 SE 的本地状态如果为 FAILED ，错误计数减小，当错误计数减小到 0 后，其 SE 的本地状态将切换至 OK。

5.1.2 Deadline Supervision
某些场景下，应用程序需要关注某段程序运行的时间（非周期性的），过长或过短都说明程序执行异常。在 WdgM 中，称之为 DeadlineSupervision，抽象为监控两个 CP 之间运行的时间。DeadlineSupervision 具体算法如下：用户将在 WdgM 中配置DeadlineSupervision 的起始 CP、结束 CP、最小时间门限和最大时间门限。在运行到起始 CP 时启动 DeadlineSupervision，在运行到结束 CP 时，计算运行时间是否配置合理范围内。
DeadlineSupervision中不仅仅可以监测最简单的两个CP之间运行的时间，也可以配置成多个链式的。如下图：

使用 DeadlineSupervision 的注意事项如下：
1. DeadlineSupervision 的两个 CP 必须属于相同的 SE；
2. DeadlineSupervision 的两个 CP 不能相同；
3. 同一 CP 可以属于不同的 Deadline Supervision；
4. DeadlineSupervision 监控到错误后，其 SE 的本地状态将直接切换至 EXPIRED，进而引起全局状态的切换；
5. Deadline 监控的时间一般是 us 级别的，而 WdgM 的调度周期是 ms 级别的，因此WdgM 需要调用 AUTOSAR OS 提供的标准接口StatusType GetElapsedValue(CounterType CounterID, TickRefType Value,TickRefType ElapsedValue)，来读取时间，才能使用 DeadlineSupervision

使用 Deadline Supervision有如下限制：
1. Deadline Supervision不支持嵌套式（i.e . start 1, start 2, end 2, end 1）;

5.1.3 Logical Supervision
Logical Supervision主要用于监控应用程序的运行顺序是否正确，包括各个 SE 本地的运行路径的检查的Internal Graph;，和 SE 之间的全局路径检查External Graph。
Internal Graph : 所有的CP都属于同一个SE中；
External Graph：至少两个CP属于不同的SE中；
不仅如此，这两种Graph还有一个区别：就是External Graph由Mode决定（每个Mode中的External Graph可能不一样），而Internal Graph则是SE的属性，不随Mode改变。
使用 Logical Supervision有如下限制：
1. 一个CP不能属于不同的Graph，包括Internal Graph和External Graph;
2. Logical Supervision不能使用在不同的调度任务中；
注：一个Graph可能有一个或者多个起始CP，并且也可能有多个终止CP；以任何起始CP开始和终止CP结束的Graph都是正确的。

5.2 WdgM状态机
WdogM模块里面有两种状态机：一种是每个SE的Local Supervision Status，还有就是整个WdogM模块的Global Supervision Status。

5.2.1 本地状态机
每个 SE都有一个专属独立的状态机，其状态转换关系描述如下：

5.2.2 全局状态机
Global Supervision Status状态切换如下图所示：
一般来说，Global Supervision Status是根据各个 SE 的本地状态来变化的，变化规则描述如下：
1. 所有 SE 的状态均为 OK，或 DEACTIVATED 时，全局状态为 OK；
2. 一个或多个 SE 的状态为 FAILED，其他 SE 为 OK 或 DEACTIVATED 时，全局状态为FAILED；
3. 一个或多个 SE 的状态为 EXPIRED，全局状态为 EXPIRED；
4. 全局状态为 EXPIRED 超过 WdgMExpiredSupervisionCycleTol 个调度周期，全局状态切换为 STOPPED。

下述情况下，也会发生全局状态切换：
5. 未初始化，或调用反初始化，全局状态切换为 DEACTIVATED；
6. 初始化时，全局状态切换为 OK；
7. 调用 WdgIf_SetMode 返回 E_NOT_OK，全局状态切换为 STOPPED；
8. 调用 WdgM_PerformReset，全局状态切换为 DEACTIVATED；
9. 调用 WdgM_SetMode 时，会引起各 SE 的本地状态变化，进而引起全局状态的变化，规则同上文描述。

下面描述了当WdgM模块的Global Supervision Status状态发生切换时，WdgM会进行相关操作：
1. Global Supervision Status为OK时，正常调用 WdgIf_SetTriggerCondition 刷新喂狗条件；
2. Global Supervision Status切换至 FAILED 时，正常调用 WdgIf_SetTriggerCondition 刷新喂狗条件。调用 BswM_WdgM_RequestPartitionReset，可以复位部分的 APP，该功能是可选的；
3. Global Supervision Status切换至 EXPIRED 时，正常调用WdgIf_SetTriggerCondition 刷新喂狗条件；
4. Global Supervision Status切换至 STOP 时，调用 WdgIf_SetTriggerCondition 将喂狗条件设置为 0，调用 Dem 上报错误事件，如果使能了 WdgMImmediateReset，会立即出发 MCU复；
5. 所有的状态切换均会通知给上层。
InternalTransition不需要切换mode，总是被监测

这里有个思考题：如果三种检测机制的Init CP 都不到达，那么会继续喂狗？
答：不会。虽然Deadline Supervision 和Logic Supervision 不到达 Init CP不会让Gloal status变成stop, 但是在Alive Supervision中则会认为程序异常，则会停止喂狗。

7.WdgIf功能简介
WdgIf主要能够添加看门狗设备和提供Wdgif_SetMode、WdgIf_SetTriggerCondition控制看门狗驱动层。

8.Wdg Driver功能简介
MCAL Wdg模块定义了三种模式，具体定义见下表：
其实mode中的喂狗频率是指中断的快慢，这个需要按需求来实现；
接下来可以看看具体喂狗的时间轴；i.e .Condition Value为180ms，Wdg ResetTime和Refresh Time都为100ms。如之前所提到的Gpt中断只会喂一次狗，而程序是否复位则取决于第二次Wdg ResetTime溢出之前是否有Condition Value刷新。

9.实现方案简介
注意点：

外狗驱动的初始化得放在BswM_Init之前，准确的说是，须放在WdgM_init之前
WdgM_MainFunction的周期须比SE的周期短；且须保证涉及的调度周期准确。
Gpt的中断周期须为连续模式
如果为窗口式看门狗，则GPT的周期为窗口的中间点；如果为非窗口式，则周期等于看门狗超时时间（这里细节上的东西比较多，就不一一讲解了，比如由于运算导致的小数处理等。总之，GPT的周期中断需保证小于Wdg硬件超时时间，或者GPT中断优先级高于Wdg的中断优先级）
smu需要配置发生wdg寄存器之后的安全处理动作
smu、wdg、WdgM初始化不能漏掉