看门狗在嵌入式系统中的作用是个什么？

看门狗技术是20世纪80年代由美国半导体巨头AMD公司首次提出，是一种专门用于检测、记录处理器运行状况以及在异常情况下复位的一种技术，随着技术的不断的迭代，看门狗逐渐发展成一类专门的芯片，广泛应用于汽车、工业自动化、物联网等领域。

此狗非彼狗！！！

软件会在执行完特定指令后进行喂狗，若在一定周期内看门狗没有收到来自软件的喂狗信号，则认为系统故障，会进入中断处理程序或强制系统复位。系统上电后根据不同的工作模式可以选择使能看门狗，若看门狗被使能则计数器开始计数，如果在设定的时间内没有及时喂狗则会发生看门狗超时。通过寄存器对看门狗进行基本设置，计数器计算狗叫时间，狗叫模块决定看门狗超时后发出的中断或复位方式。

看门狗发展至今，功能已经发展的比较完善，所以已经有很多比较详细且角度不同的分类，例如按照种类分可以分为硬件看门狗和软件看门狗；按照与单片机集成性可以分为内部看门狗和外部看门狗；

以汽车产品中最通用的英飞凌的TLF35584芯片为例，该电源管理芯片通过了ISO26262的ASILD的认证，并且集成了看门狗模块，该看门狗模块既属于硬件看门狗，同时也属于外部看门狗。由Window Watchdog和Functional Watchdog组成，（后面简化成为WWD和FWD）

Window Watchdog和Functional Watchdo

1. 功能看门狗与窗口看门狗不同步，两者完全独立。
2. 功能看门狗和窗口看门狗可以独立激活和禁用。
3. 看门狗的结果（有效或无效触发）由相关看门狗故障计数器独立监控。
4. 窗口看门狗的状态为WWO，其值可能为“有效WWD 触发”或“无效WWD 触发”。
5. 功能看门狗的状态为FWO，其值可能为“有效FWD 触发”或“无效FWD 触发”。
6. 两个看门狗的设置对安全状态控制的影响在安全状态控制一章中进行了描述，以便更好地理解。

我们称作窗口看门狗或时间看门狗，首先被监控的控制器（MCU）必须在Open Window期间内触发（就是指喂狗操作），喂狗可以通过 WDI 引脚上的下降沿或通过 SPI 命令写入寄存器 WWDSCMD，具体取决于配置。触发后将终止“Open Window”。 看门狗输出指示 WWD 故障计数器的“有效”或“无效”WWD 触发。

如果有效触发，则启动“Closed Window”。如果在“Open Window”期间没有触发或在“Closed Window”期间触发，看门狗输出指示“无效 WWD 触发”到 WWD 失败计数器，并启动新的“Open Window”。

1.WWD工作状态图

Window Watchdog State

1. “触发”可以是发送到 WWDSCMD 寄存器的 SPI 命令，也可以是 WDI 引脚上的有效看门狗触发
2. “Long open Window”中“No Trigger”被视为“无效WWD 触发”，看门狗会再次打开一个“Long Open Window”
3. “Long open Window”内的“触发”被视为“有效 WWD 触发”，看门狗关闭“Long open Window”并打开“Closed Window”
4. “CLosed Window”内的“触发”被视为“无效WWD触发”
5. “Closed Window”结束后，“Closed Window”内的“无触发”会将看门狗移至“Open Window”。
6. “Open Window”内的“触发”被视为“有效WWD 触发”，看门狗关闭“Open Window”并打开“Closed Window”
7. “Open Window”中的“无触发”被视为“WWD 触发无效”。

2.WDI引脚触发WWD

看门狗输入引脚 WDI 具有集成的下拉电流 IWDI 。 看门狗输入 WDI 可以在“Closed Window”内或随后的“Open Window”期间转换为高电平。

WDI引脚

• WD的有效触发信号

看门狗输入 WDI 以TSAMT周期定期采样。 有效触发信号是从VWDIV,高电平到VWDIV,低电平的下降沿。 为了提高 WDI 输入上的抗噪声或毛刺的能力，有效触发信号至少需要两个高采样点，然后是两个低采样点，通过测量低信号的第二个连续采样点来考虑有效触发。 例如，如果引脚 WDI 处的触发脉冲的前三个采样（两个高一个低）位于“关闭窗口”内，并且仅在“打开窗口”中采集第四个采样（第二个低采样），则看门狗 输出 WWO 将指示“有效 WWD 触发”。

• WDI 触发无效

在“Open Window”期间未检测到触发信号或在“Closed Window”期间检测到触发信号，均视为无效触发。 看门狗输出 WDO 在“Open Window”期间无有效触发后立即指示“无效触发”，或者在“Closed Window”期间检测到触发信号后立即指示“无效触发”。

WDI有效触发和无效触发

3.WWD正常工作——正确触发

正确触发

1. 如果 ROT（监控微控制器相关电压）的复位输出变高，则“Long Open Window”在 INIT 状态下启动。 如果窗口看门狗在睡眠状态下被停用，则第一个Open Window将从睡眠状态转换到唤醒状态（由中断指示）开始。 第一个Open Window的时间取决于配置的周期时间，为 600 ms (WDCYC = 1) 或 60 ms (WDCYC = 0)。
2. 在“Long Open Window”期间，预计会根据配置的触发选择有效触发 WWD。 “长Open Window”的最长时间是固定的，但一旦识别到“有效 WWD 触发”，它就会终止。
3. 窗口看门狗现在将进入“Closed Window”。 收到第一个有效触发后，设备将被允许从 INIT 状态移至 NORMAL 状态或从 WAKE 状态移至 NORMAL 状态。
4. “Closed Window”具有固定的持续时间 tWD,CWt_{WD,CW} （可以通过SPI 命令确定）。 它在有效触发信号后立即启动，关闭“Open Window”或“长Open Window”。 在“Closed Window”期间不应施加触发信号。 不会检测到 WDI 引脚从低电平到高电平的转换，也不会导致触发事件。
5. 有效的触发信号立即终止“Open Window”，因此“Open Window”的时间是可变的，并且取决于微控制器安排触发的时间。 这被视为“有效 WWD 触发”。

4.WWD异常工作——在“Long Open Window”未触发

在Long Open Window未触发

1. 初始化超时和Long Open Window（LOW）具有相同的典型值。 长度。 通常这会导致初始化超时在低电平之前或同时完成，这将跳过中断事件 (1)。 尽管由于给定的精度，“Long Open Window”内缺少有效触发可能会在低电平结束后导致中断事件，从而使窗口看门狗故障计数器增加 2。
2. INIT状态定时器第一次超时。 由于在 INIT 状态期间未按预期接收到窗口看门狗的有效触发，因此将发出所谓的“软复位”：引脚 ROT 变为零，但后置稳压器的输出电压保持开启状态。附加信息：如果窗口看门狗在接下来的 INIT 阶段的下一个“Long Open Window”内未正确触发，将发出“硬复位”，这意味着引脚 ROT 将变为零，并且输出电压将 也被关闭。 在 INIT 阶段第三次无效触发后，设备将进入 FAILSAFE 状态。
3. 经过上电复位延迟时间trd后，所谓的“软复位”引脚ROT再次变高，看门狗打开一个“Long Open Window”，让微控制器有机会触发并同步到看门狗周期 。
4. 有效触发终止“Long Open Window”，这使得“Long Open Window”的持续时间可变并取决于触发。 这被视为“有效 WWD 触发”并启动“Closed Window”。 在不发出中断的情况下，窗口看门狗故障计数器将减 1。
5. 接下来的“Closed Window”持续时间 tWD,CWt。 在此时间内触发将被视为“无效WWD触发”。

5.WWD异常工作——在“ Open Window”未触发

在Open Window未触发

1. “Open Window”内缺少有效触发，导致窗口结束后出现“无效 WWD 触发”。 该事件由中断指示，窗口看门狗故障计数器增加 2。
2. 检测到“无效 WWD 触发”后，看门狗将启动一个持续时间为 tWD,CWt_{WD,CW} 的新“Open Window”，以使微控制器有机会触发并同步到看门狗周期。
3. 有效触发终止“Open Window”，这使得“Open Window”的持续时间可变并取决于触发。 这被视为“有效 WWD 触发”并启动“Closed Window”。 在不发出中断的情况下，窗口看门狗故障计数器将减 1。
4. 如果“Open Window”内出现多次“无效 WWD 触发”，窗口看门狗故障计数器将再次增加 2，直到达到配置的阈值。 在这种情况下，将发出重置命令。
5. 接下来的“Closed Window”持续时间 tWD,CWt_{WD,CW} 。 在此时间内触发将被视为“无效WWD触发”。

引脚 ROT 的行为取决于 ΣWWO 的值。 在上面的例子中，假设无效触发不会导致超过阈值ΣWWO。

6.WWD异常工作——在初始化之后的“Closed Window”中错误的触发

1. “Closed Window”期间的触发被指示为“无效WWD触发”。 该事件由中断指示，并且窗口看门狗故障计数器增加 2。
2. “Closed Window”将因“WWD 触发无效”而关闭。 最初它会持续时间 tWD,CWt_{WD,CW} 。 错误触发终止“Closed Window”并启动“Open Window”，以使微处理器有机会同步到窗口看门狗周期。
3. 在此“Open Window”内预计会发生有效触发。 有效的触发会终止“Open Window”，这使得“Open Window”的持续时间可变并取决于触发。 这被视为“有效 WWD 触发”并启动“Closed Window”。 在不发出中断的情况下，窗口看门狗故障计数器将减 1。
4. 接下来的“Closed Window”持续时间 tWD,CWt_{WD,CW} 。 在此时间内触发将被视为“无效WWD触发”。

引脚 ROT 的行为取决于 ΣWWO 的值。 在上面的例子中，假设无效触发不会导致超过阈值ΣWWO。

7.WWD异常工作——在稳态“Closed Window”错误的触发

在Close Window中错误的触发

1. “Closed Window”期间的触发被指示为“无效WWD触发”。 该事件由中断指示，并且窗口看门狗故障计数器增加 2。
2. “Closed Window”将因“WWD 触发无效”而关闭。 最初它会持续时间 tWD,CWt_{WD,CW} 。 错误触发终止“Closed Window”并启动“Open Window”，以使微处理器有机会同步到窗口看门狗周期。
3. 在此“Open Window”内预计会发生有效触发。 有效的触发会终止“Open Window”，这使得“Open Window”的持续时间可变并取决于触发。 这被视为“有效 WWD 触发”并启动“Closed Window”。 在不发出中断的情况下，窗口看门狗故障计数器将减 1。
4. 接下来的“Closed Window”持续时间 tWD,CWt_{WD,CW} 。 在此时间内触发将被视为“无效WWD触发”。
5. 引脚 ROT 的行为取决于 ΣWWO 的值。 在上面的例子中，假设无效触发不会导致超过阈值ΣWWO。

我们称作功能看门狗或问答看门狗。 在稳定状态下，会生成一个问题（从表中取出），同时心跳计数器从零开始计数。 心跳计数器开始计数，直到心跳周期结束。 心跳周期的持续时间可以通过 SPI 命令进行设置和调整。

问题由 4 bits组成，预期答案由 4 个回复组成，每个回复为 8 位。 这四个回复应在心跳周期结束之前发送。 最后回复应写入同步回复寄存器以重置心跳计数器。

Functional Watchdog的问题与回复

功能看门狗输出 FWO 是一个内部信号：它连接到 FWD 故障计数器。 功能看门狗 FWO 输出的值为“有效 FWD 触发”或“无效 FWD 触发”。

1.FWD工作流程图

FWD工作流程图

步骤如下：

1. 首先判断FWD是否使能；如果未使能，停止并清空心跳计数器值；如果使能，请跳至步骤2；
2. 开启心跳计数器，并生成初始化问题；
3. 设置response byte number为3，准备接受第一个回复；
4. 等待回复值；
5. 判断心跳计数器是否超时，如果超时，重置心跳计数器，FWD故障计数器加2，请跳至步骤4；如果未超时，请跳至步骤6；
6. 判断新的回复值是否收到？如果未收到，请跳至步骤4；如果收到了，请跳至步骤7；
7. 判断是否为最后一个回复？如果不是，将response byte number减1，请跳至步骤4；如果是，请跳至步骤8；
8. 判断是否同步了回复？如果未同步，请跳至步骤9；如果同步了，重置心跳计数器，也请跳至步骤9；
9. 判断回复是否正确？如果不正确，请跳至步骤10；如果正确，FWD故障计数器减1，生成新的问题，请跳至步骤3；
10. 判断是否同步了回复？如果未同步，请跳至步骤3；如果同步了FWD故障计数器加2，也请跳至步骤3。

2.FWD正常工作——正确触发

正确触发模式

步骤如下：

1. 生成一个新问题，同时心跳计数器开始计数（假设之前发生过“有效 FWD 触发”）
2. 收到正确的回复（RESP3）
3. 收到正确的回复（RESP2）
4. 收到正确回复（RESP1）
5. 收到正确的同步回复（RESP0）。 所有回复均正确，回复顺序正确，并且在心跳计数器溢出之前收到最后一个同步回复。 心跳计数器将被重置（设置为零）。 这被视为“有效 FWD 触发”，功能看门狗错误计数器 ΣFWO 减 1（如果功能看门狗错误计数器值大于零）
6. 生成一个新问题，同时心跳计数器开始计数

3.FWD异常工作——同步丢失

同步丢失

步骤如下：

1. 生成一个新问题，同时心跳计数器开始计数（假设之前发生过“有效 FWD 触发”）
2. 收到正确的回复（RESP3）
3. 收到正确的回复（RESP2）
4. 收到正确回复（RESP1）
5. 接收到正确的回复（RESP0），但未同步（写入错误的寄存器）。 到目前为止，所有回复都是正确的，回复顺序是正确的，并且在心跳计数器溢出发生之前收到了最后一个不同步的回复。 心跳计数器不会被重置并继续计数。 这被视为“有效 FWD 触发”，功能看门狗错误计数器 ΣFWO 减 1（如果功能看门狗错误计数器值大于零）。 生成了一个新问题
6. 心跳计数器仍在计数，等待新问题的回复。 心跳计数器将到期并发生溢出。 这被视为“无效 FWD 触发”。 这功能看门狗错误计数器 ΣFWO 加 2。心跳计数器复位
7. 心跳计数器开始计数。，不会产生新问题

4.FWD异常工作——回答错误

回答错误

步骤如下：

1. 生成一个新问题，同时心跳计数器开始计数（假设之前发生过“有效 FWD 触发”）
2. 收到正确的回复（RESP3）
3. 收到正确的回复（RESP2）
4. 收到错误回复(RESP1)
5. 收到正确的回复（RESP0）， 心跳计数器将被重置（设置为零）， 完整的答案是不正确的。 这被视为“无效 FWD 触发”。 功能看门狗错误计数器 ΣFWO 加 2。心跳计数器复位
6. 没有生成新问题，但心跳计数器开始计数

注意：如果将Resp2和Resp1混合在一起，则将两个回复视为不正确的，则必须按正确的顺序发送回复。

5.FWD异常工作——回复丢失

回复丢失

步骤如下：

1. 生成一个新问题，同时心跳计数器开始计数（假设之前发生过“有效 FWD 触发”）
2. 收到正确的回复（RESP3）
3. 收到正确的回复（RESP2）
4. 缺少回复(RESP1)
5. 收到正确的回复（RESP0）。 因此，由于缺少回复（在此示例中为 RESP1），最后一个回复不是最后一个回复，而是倒数第二个回复。 功能看门狗将等待所有四个回复被写入，而心跳计数器继续计数。 所有四个回复没有固定时间，但必须在心跳计数器到期之前以正确的顺序发送
6. 由于缺少回复RESP1，完整答案不正确。 虽然最后的回复是同步的，但是心跳计数器不会被重置并继续计数，直到发生溢出。 这被视为“无效 FWD 触发”。 功能看门狗错误计数器 ΣFWO 加 2。心跳计数器复位
7. 不再生成新问题，心跳计数器开始计数

1.功能安全标准软件部分要求

首先在功能安全标准第6章，7.4.12中提到，应使用看门狗进行软件的时间监控和程序流监控。

ISO26262标准第6章

2.功能安全标准硬件部分要求

在第5章的附录中，也提到了不同看门狗的功能和诊断覆盖率

看门狗的诊断覆盖率

功能安全标准

标准中分别介绍几种看门狗的目标和功能描述，我在这里归纳总结一下在ISO26262中，看门狗作为安全机制的一些用法和要求

看门狗的作用

1.功能安全对看门狗的要求

标准并没有明确给出不同的ASIL等级如何使用看门狗，下面是个人根据自身的项目经验，给出的一些建议，仅供参考。

看门狗监控的使用建议

2.内部看门狗VS外部看门狗

内部看门狗与外部看门狗

3.看门狗监控机制的作用

看门狗监控机制

1.静态架构

首先看一下Autosar中看门狗功能的静态架构，看门狗在Autosar中属于非常标准的功能，架构层面也比较清晰。

Autosar看门狗静态架构

Autosar的看门狗结构主要有：

内部看门狗：WatchDog Manager，WatchDog Interface, WatchDog Driver，On Chip WatchDog

外部看门狗：WatchDog Manager，WatchDog Interface, SPI，Off Chip WatchDog

分别对应Autosar中的服务层，ECU抽象层，控制器抽象层（MCAL）和硬件

Autosar的看门狗模块

值得注意的是内部看门狗可以通过WatchDog Driver去访问，比较简单；而外部看门狗需要使用SPI通信或者其他方式进行访问，相比内部看门狗复杂一点。

被监控实体（Supervised Entity）：就是你想要监控的对象，它可以是一个SWC、运行实体、BSW模块或者复杂驱动。

检查点（Check Point）：在被监控实体中的重要的位置插入一些点叫做检查点，后面所有的计算和检查都基于这些检查点。

2.动态架构

如下图所示为Watchdog初始化，触发看门狗喂狗以及改变看门狗模式的的三类函数调用场景。

1. Watchdog初始化：通过EcuM模块调用函数Wdg_Init来完成Watchdog的初始化配置；
2. 触发看门狗喂狗：通过WdgM模块调用WdgIf模块提供的函数WdgIf_SetTriggerCondition来触发底层驱动进行喂狗动作；
3. 改变看门狗模式：通过WdgM模块调用WdgIf模块提供的函数WdgIf_SetMode来实现看门狗模式的改变。

看门狗喂狗过程1

下图为Wathdog 驱动与底层看门狗硬件交互的时序图，可以看出WdgIf_SetTriggerCondition中会继续调用Wdg驱动中函数Wdg_SetTriggerCondition来实现喂狗动作。

看门狗喂狗过程2

该模块提供了初始化硬件看门狗，改变操作模式，设置触发看门狗喂狗方式等功能。同时，可以按照该看门狗是否位于芯片内部，可以将位于芯片内部的看门狗称为内部看门狗，位于芯片外部的看门狗称为外部看门狗

不论是内部看门狗还是外部看门狗，对于Watchdog Driver而言其使用的看门狗驱动的API应始终保持一致。只不过内部看门狗而言，其驱动属于MCAL层，而对于外部看门狗则属于ECU硬件抽象层，该外部看门狗驱动需调用MCAL中其他驱动来实现喂狗动作，如GPIO，IIC或者SPI等驱动。

以英飞凌TLF35584为例，需要SPI驱动

TLF35584芯片看门狗系统框图

在AUTOSAR架构中，针对Watchdog Driver而言，定义了看门狗控制模式存在如下三种模式：

• Off Mode：表示看门狗关闭状态，对于关键安全系统，一般不能将其切换至Off状态，一旦打开将不能被关闭；
• Slow Mode：表示看门狗的一个长时间喂狗窗口，该模式一般用于系统启动初始化过程中；
• Fast Mode：表示看门狗的正常喂狗窗口喂狗模式，该模式运用在系统正常运行的过程中。

Watchdog If模块全称为Watchdog Interface接口，该接口作为底层Watchdog Driver的抽象，是为了实现底层硬件与软件之间的解耦。

该模块的基本功能仅仅作为底层驱动的抽象层来实现底层看门狗驱动与上层看门狗管理模块的交互，底层看门狗驱动的特性，如窗口控制，时间周期等设置都不能通过Watchdog If模块来完成。

如果超过一个看门狗驱动被上层Watchdog Manager进行管理，那么DeviceIndex将需要被检查，如果出现错误，需要及时上报。

Watchdog If模块整体来说，配置比较简单

函数：

1. WdgIf_SetMode：设置看门狗模式
2. WdgIf_SetTriggerCondition：出发喂狗操作
3. WdgIf_GetVersionInfo：获取看门狗模块的Autosar版本信息

参数：

1. WdgIfVersionInfoApi:是否使能Autosar版本读取功能
2. WdgIfDevErrorDetect:手机否使能模块错误Det错误检测功能 TRUE使能， FALSE禁用
3. WdgIfDeviceIndex:支持多个看门狗驱动的索引
4. WdgIfDriverRef:当前看门狗的索引

WatchDog Interface参数

1.基本工作过程

当Supervised Entities执行时，每当运行到某一Checkpoint时，会调用对应的WdgM接口上报状态。一个Supervised Entity可以拥有一个或者多个Checkpoint，它们在Supervised Entity内部的关联信息构成了一个Graph，也可以叫它Internal Graph，不同Supervised Entities之间的Checkpoints的关联则构成了External Graph。 每一种WdgM模式下都可以有多个External Graph，在一个Graph中，可以有多个Initial Checkpoint或者多个Final Checkpoints，这种情况下，无论从哪一个Initial Checkpoint开始这个执行流程都可以，同样，无论在哪个Final Checkpoint结束此次执行流程也是可以的。

一个Supervised Entity可以同时设置多种Supervision机制，基于每一种机制返回的状态，可以计算出当前Supervised Entity的状态，也即Local Status。 当每一个Supervised Entity的状态都得到的时候，就能计算出整个MCU的状态了，也即Global Supervision Status。每一种Supervision功能都会返回状态列表，代表正确或者不正确，最后对于每一个Supervised Entity来说会有三个状态，Alive Supervision状态，Deadline Supervision状态，Logical Supervision状态。然后计算出本地状态，也即绿色框所示。最后是红色框所示的全局状态。 执行WdgM_CheckpointReached()函数，会更新Deadline Supervision和Logical Supervison的状态，执行WdgM_Mainfunction()更新Alive Supevision的状态。

整体工作过程

2.本地状态更新

Local Supervision Status

1. 路径1：如果三种监控状态都返回的是正确，并且最近一次记录的本地状态是OK，那么本地状态将停留在OK状态
2. 路径2：如果上次记录的本地状态是OK，满足任一条件时，本地状态为EXPIRED： 至少一个Alive Supervision返回的是incorrect，且容忍度（Tolerance）设置为0 至少一个Dealine Supervision或者Logical Supervision返回的状态时incorrect
3. 路径3：如果上次记录的本地状态是OK，同时满足以下两个条件时，本地状态为FAILED： 至少一个Alive Supervision返回的是incorrect，且容忍度（Tolerance）大于0 所有的Dealine Supervision或者Logical Supervision返回的状态都是correct.
4. 路径4：如果上次记录的本地状态是FAILED，同时满足以下两个条件时，本地状态保持FAILED： 至少一个Alive Supervision返回的是incorrect，且失败次数小于容忍度（Tolerance） 所有的Dealine Supervision或者Logical Supervision返回的状态都是correct. 或者 至少一个Alive Supervision返回的是incorrect，且错误次数大于1 所有的Dealine Supervision或者Logical Supervision返回的状态都是correct.
5. 路径5：如果上次记录的本地状态是FAILED，同时满足以下两个条件时，本地状态为OK： 所有的Alive Supervision返回的是correct，且错误计数器等于1 所有的Dealine Supervision或者Logical Supervision返回的状态都是correct.
6. 路径6：如果上次记录的本地状态是FAILED，满足以下任一条件时，本地状态为EXPIRED： 至少一个Alive Supervision返回的是incorrect，且失败次数等于于容忍度（Tolerance） 至少一个Dealine Supervision或者Logical Supervision返回的状态时incorrect。
7. 路径7：如果激活后禁用，则设置为DEACTIVATED状态。
8. 路径8：如果禁用后，Wdg函数没有监控任何SE，则维持为DEACTIVATED状态。
9. 路径9：如果禁用后激活，则切换到OK状态。
10. 路径10：WdgM初始化后，在初始化模式激活的SE的本地状态将处在OK状态。
11. 路径11：如果不在初始化模式激活，SE的本地状态将处在DEACTIVATED状态。
12. 路径12：如果上一次状态是FAILED，禁用后切换到DEACTIVATED状态。

3.全局状态更新

全局状态更新

1. 路径1：上次记录的全局状态为OK，当前SE的本地状态为OK或者DEACTIVATED，全局状态保持在OK。
2. 上次记录的全局状态为OK，当前SE至少有一个本地状态是FAILED，且没有SE状态是EXPIRED，全局状态为FAILED。
3. 上次记录的全局状态为OK，当前至少有一个SE的本地状态是EXPIRED，且未超过阈值，全局状态为EXPIRED。
4. 上次记录的全局状态为OK，当前至少有一个SE的本地状态是EXPIRED，且超过阈值，全局状态为STOPPED。
5. 上次记录的全局状态为FAILED，当前至少有一个SE的本地状态是FAILED，且没有EXPIRED，全局状态将保持在FAILED。
6. 上次记录的全局状态为FAILED，当前所有的SE的本地状态是OK或者DEACTIVATED，全局状态为OK。
7. 上次记录的全局状态为FAILED，当前至少有一个SE的本地状态是EXPIRED，且未超过阈值，全局状态为EXPIRED。
8. 上次记录的全局状态为FAILED，当前至少有一个SE的本地状态是EXPIRED，且超过阈值，全局状态为STOPPED
9. 上次记录的全局状态为EXPIRED，当前至少有一个SE的本地状态是EXPIRED，且未超过阈值，全局状态将保持在EXPIRED
10. 上次记录的全局状态为EXPIRED，当前至少有一个SE的本地状态是EXPIRED，且超过阈值，全局状态为STOPPED
11. 上次记录的全局状态为STOPPED，全局状态将保持在STOPPED
12. 如果调用WdgIf_SetMode失败，全局状态为STOPPED
13. 路径13：当WdgM初始化函数调用之后，全局状态为OK
14. 路径14：如果上一次全局状态为OK，成功调用WdgM_DeInit之后，全局状态为DEACTIVATED。
15. 路径15：如果上一次全局状态为FAILED，成功调用WdgM_DeInit之后，全局状态为DEACTIVATED。
16. 路径16：如果上一次全局状态为EXPIRED，成功调用WdgM_DeInit之后，全局状态为DEACTIVATED。
17. 路径17：如果上一次全局状态为STOPPED，成功调用WdgM_DeInit之后，全局状态为DEACTIVATED。
18. 路径18：WdgM的全局状态，初始化状态为DEACTIVATED。

1.Alive Supervision

1.参数配置

如下图所示为Alive Supervision的监控方式，可以看到对于监控实体SE3中只有有一个Checkpoint3-1

Alive Supervision参数

在上图中我们看到配置Alive Supervision，需要配置下如下四个基本参数：

1. WdgMExpectedAliveIndications：在给定的时间内某监控实体SE调用WdgM_CheckpointReached函数的次数，即Expected值；
2. WdgMMaxMargin：调用上述函数的次数的增加的偏移值，即实际值=Expected值+WdgMMaxMargin；
3. WdgMMinMargin：调用上述函数的次数的减少的偏移值，即实际值=Expected值-WdgMMinMargin；
4. WdgMSupervisionReferenceCycle：基于WdgM_Mainfunction调用函数周期的次数作为监控参考周期。

2.工作原理

1. 调用一次WdgM_CheckpointReached --> 发送一次Alive indication --> Alive Counter+1
2. 通过 WdgMSupervisionReferenceCycle 设定 WdgMSupervisionCycle，应该是它的整数倍
3. Expected-MinMargin < WdgM_CheckpointReached调用次数 < Expected+MaxMargin，如果超出此范围，报监控错误状态，即会影响到该SE的Local Status状态。
4. 为了避免出现有时间设定的WdgM_CheckpointReached函数调用次数为0或者1时，可能会出现即使该监控实体不再执行时，也会出现满足许可调用次数的情况，一般设计建议选取WdgM主函数周期及监控实体SE所在任务周期两者之间的最小公倍数来设置监控参考周期，确保每个监控参考周期内的WdgM_CheckpointReached()函数调用次数都是固定值，此时，上下偏差MinMargin和MaxMargin均设为0即可。

2.Deadline Supervision

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

1.参数配置

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

如下图所示为SE4的Deadline Supervision监控方式，存在一个Start Checkpoint4-1以及End Checkpoint4-2.

基本参数如下：

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

如下图所示为SE4的Deadline Supervision监控方式，存在一个Start Checkpoint4-1以及End Checkpoint4-2

Deadline Supervision监控1

下图所示为某个SE实体同时存在多个Checkpoint的场景，在该类场景下，彼此之间不存在多大关联，仅在于相邻Checkpoint之间的执行时间的测量。 值得注意的是该类监控的SE中不同Checkpoint不允许存在嵌套行为，如CP Start1, CP Start2, CP End2, CP End1。

Deadline Supervision监控2

2.工作原理

1. 对于此类监控模式，必须有两种Start Checkpoint以及End Checkpoint两类 Start Checkpoint --> 通过参数 WdgMDeadlineStartRef 设定 End Checkpoint --> 通过参数 WdgMDeadlineEndRef 设定
2. 需要使用OS Counter去计算两个Checkpoint之间的时间间隔
3. 为了确定WdgM_CheckpointReached调用时的时间戳以及两个Checkpoint之间Transition的时间，那么调用的函数WdgM_CheckpointReached中需要使用OS功能计算两个Checkpoint之间的时间差距；
4. 通过两个Checkpoint之间Transition所经历的OS tick时间，并与配置的时间参数WdgMDeadlineMin以及WdgMDeadlineMax进行比较，如果超过限值，则报出该监控实体Deadline Supervision错误

3.Logical Supervision

1.配置过程

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

Autosar中程序流监控示例

如上图的7个Checkpoint，其简化模型如下图所示：

程序流监控

上图中描述了程序执行可能的路径，每个路径都通过Checkpoint来进行设定，那么便得到了上面所有的可能性，这些Checkpoint的Transition关系需要在配置中进行体现。

2.工作原理

1. 当程序运行至Checkpoint处，则调用WdgM_CheckpointReached()函数；
2. 在该函数体内会记录上一次的Checkpoint Id以及两个Checkpoint之间的Transition Id，其中Transition Id根据相邻两Checkpoint计算得到，若相邻Checkpoint之间的Transition不是预期的Transition，那么就会报出该监控实体Logic Supervision的状态错误。

来源：知乎：穷困潦倒的资本家

链接：https://www.zhihu.com/question/315309637/answer/3348304856