正文

Watchdog基本功能

眾所周知，Watchdog，中文名為看門狗，就是為了實現(xiàn)在設備無人值守的情況下系統(tǒng)出現(xiàn)異常時能夠自動完成系統(tǒng)復位操作保證整個功能的持續(xù)使用。

看門狗功能對于關鍵安全系統(tǒng)是必須的，對于非關鍵安全系統(tǒng)也是很有必要的。

為什么這么講？原因是運行在硬件世界中的軟件會受到各種外界因素的影響，如硬件自身老化損壞，外部電磁干擾等，這些都有可能導致程序在運行過程中發(fā)生不可預知的行為，而這些不可預知的行為如果沒有看門狗，那么就完犢子了，要是你這個設備在人跡罕見的沙漠地帶，毫無疑問就增加了很多不必要的維護成本。

對于汽車上使用的諸多零部件，鑒于汽車環(huán)境的惡劣，各類ECU中的軟件均有可能遭受如外部電磁干擾，高溫等環(huán)境因素的影響，從而導致程序“跑飛”或者“死機”現(xiàn)象，此時如果有看門狗的存在，便可以主動觸發(fā)系統(tǒng)復位機制保證能夠再次正常使用，而不是只能眼睜睜的看著被送到4S店進行維修，影響產品口碑或是增加不必要的售后維護成本。

基于看門狗的實現(xiàn)邏輯，一般意義上我們可以將看門狗分為硬件看門狗與軟件看門狗。

顧名思義，硬件看門狗就是通過硬件自身的機制來實現(xiàn)看門狗功能，其本質也是通過定時器原理來實現(xiàn)，只不過此時軟件的角色僅僅是使能定時器，定時器自身的變化與更新由硬件自身完成；軟件看門狗則是整個定時器的使能與更新完全由軟件來做，當然軟件也是通過定時器完成，只不過是間接方式。

硬件看門狗

如上所述，硬件看門狗依賴自身定時器來完成看門狗功能，俗稱“硬狗”。常見的硬件看門狗比如MCU內部自帶的看門狗，PMIC中內嵌的看門狗以及外部的獨立看門狗等。

至于選用何種的硬件看門狗，完全取決于自身系統(tǒng)設置需要，無法千篇一律。不過在使用硬件看門狗的時候需要特別考慮以下兩點：

該硬件看門狗的最大超時時間能否滿足系統(tǒng)設計需求，如果該超時時間過小，就會導致整個系統(tǒng)的不穩(wěn)定性，誤觸發(fā)看門狗；

該硬件看門狗是否可以進行關閉，對于關鍵安全系統(tǒng)，一般都要求看門狗一旦打開將不允許被關閉；

該硬件看門狗系統(tǒng)上電后默認處于開狗還是關狗狀態(tài)，如果是默認開狗，那么對于軟件而言，需考慮芯片上電后便要進行喂狗或者重置看門狗行為，同時設計一種在刷件或者調試軟件前的物理關狗動作。

該硬件看門狗是采用哪種方式進行喂狗，如通過GPIO，IIC或者SPI等通訊方式來喂狗，因為不同的通訊喂狗方式對芯片的硬件資源均有要求，盡可能采用相對簡單可靠的通訊方式來喂狗即可，小T認為GPIO優(yōu)于IIC，IIC優(yōu)于SPI。

如下圖1列舉了市面上存在的不同通訊方式喂狗的硬件看門狗：

GPIO喂狗硬件看門狗：

IIC喂狗硬件看門狗：

SPI喂狗硬件看門狗：

圖1 各類喂狗方式硬件看門狗

軟件看門狗

軟件看門狗如上所述，屬于通過軟件定時器的方式來實現(xiàn)看門狗功能，俗稱“軟狗”。軟件看門狗的時間本質上也需要依賴硬件外設上的硬件定時器。

比如常見的我們會通過ostick的方式來進行記時功能，通過一個task運行軟狗監(jiān)控的定時器不斷遞減的主程序，其他task程序則是重置定時器，如果軟件監(jiān)控主程序某個task的定時器歸零，那么此時可以便可以判斷其他task并沒有被正常的執(zhí)行，此時便可以通過主動復位的方式來實現(xiàn)看門狗功能。

一般而言，運行軟狗的主任務的優(yōu)先級不應設置比被監(jiān)控的任務優(yōu)先級低，跟硬件看門狗搭配在一起使用，一般將軟狗的主任務與硬件看門狗喂狗的主任務放入同一個任務，這樣可以保證如下圖2所示的這種層級關系：

圖2 軟狗與硬狗層級關系圖

以上圖作為一個實踐案例，僅供大家參考，具體實現(xiàn)方式可以依照項目需求來定。圖中Task A，B ,C 優(yōu)先級均比Task D要低，如果在Task D中喂硬狗，那么有可能會出現(xiàn)Task D運行正常，其他任務掛死而系統(tǒng)始終運行正常的狀態(tài)，這樣就起不到硬件看門狗的保護功能。

因此為了避免喂硬狗的任務優(yōu)先級過高，導致其他低優(yōu)先級任務掛死而無法察覺，因此有必要添加軟狗來實現(xiàn)對低優(yōu)先級任務的保護。

通過Task A，B，C針對各自的計數(shù)器來進行重置，該重置的值設定需要結合各自task的最大運行時間及周期來決定，Task D則是在運行軟狗監(jiān)控主體來實現(xiàn)各個Task計數(shù)器的遞減動作，如果在重置的值時間內所有task計數(shù)器都不等于0，也就意味著其他低優(yōu)先級任務運行正常，此時便可以正常通過GPIO或IIC或SPI進行喂硬狗，否則有任意計數(shù)器為0，那么就需要停止喂狗或者主動觸發(fā)復位行為。

AUTOSAR Watchdog協(xié)議棧介紹

其實，針對上述軟狗與硬狗相結合使用的應用場景，AUTOSAR架構也已經將其標準化考慮在整個Watchdog協(xié)議棧中來實現(xiàn)，因此在實際項目的開發(fā)過程中，大家可以通過以下的學習來進一步了解基于AUTOSAR的Watchdog協(xié)議棧工作原理與使用方法。

如下圖3展示了AUTOSAR架構針對Watdog協(xié)議棧的軟件層級拓撲關系圖：

圖3 AUTOSAR架構下的Watchdog協(xié)議棧

如上圖3所示，在AUTOSAR架構下，Watchdog協(xié)議棧可以分為如下三個軟件模塊：

Watchdog Driver：用于實現(xiàn)針對硬件看門狗的寄存器操作與控制，可以分為MCU內部看門狗(Internal Watchdog)與外部看門狗(External Watchdog)，該外部看門狗可以通過GPIO或者IIC或者SPI來實現(xiàn)喂狗；

Watchdog Interface：Watchdog If作為整個Watchdog Stack的一部分，其主要功能則是為了實現(xiàn)上層Watchdog Manager與底層Watchdog Driver的連接，當然其連接的底層Watchdog Driver可以存在多個，這在多核設計中較為常見。

Watchdog Manager：Watchdog Manger模塊作為整個看門狗協(xié)議棧中的服務層，Watchdog Manager的主體功能就是為了負責整個程序執(zhí)行的正確性，并觸發(fā)相應的硬件看門狗的喂狗動作，扮演了整個監(jiān)控的核心角色。

通過上述AUTOSAR架構下的三個模塊便可以實現(xiàn)整個AUTOSAR Watchdog Stack的功能，接下來小T將針對這三個模塊進行詳細講解，保證我們都能夠對這三個模塊有個較為清晰的認識與理解，更好的運用到實戰(zhàn)中。

理解Watchdog Driver模塊

該模塊提供了初始化硬件看門狗，改變操作模式，設置觸發(fā)看門狗喂狗方式等功能。同時，可以按照該看門狗是否位于芯片內部，可以將位于芯片內部的看門狗稱為內部看門狗，位于芯片外部的看門狗稱為外部看門狗。

不論是內部看門狗還是外部看門狗，對于Watchdog Driver而言其使用的看門狗驅動的API應始終保持一致。只不過內部看門狗而言，其驅動屬于MCAL層，而對于外部看門狗則屬于ECU硬件抽象層，該外部看門狗驅動需調用MCAL中其他驅動來實現(xiàn)喂狗動作，如GPIO，IIC或者SPI等驅動。

內部看門狗

內部看門狗如前所述為芯片內部的硬件看門狗，該內部看門狗驅動一般由芯片廠商提供，不過值得注意的是在使用芯片內部看門狗前需確認該看門狗觸發(fā)的復位動作是否是冷復位，是否存在復位不完全等場景，否則可能就達不到安全監(jiān)控的目的。

內部看門狗由于其涉及到芯片內部本身，如果芯片本身硬件存在問題，可能會導致內部看門狗自身失效，從而出現(xiàn)自身難保的困境，所以從某種程度來講，對于關鍵安全系統(tǒng)，僅使用內部看門狗顯得并不安全，此時還是需要依賴于外部看門狗來保證其功能安全。

外部看門狗

外部看門狗是位于被保護芯片外部的看門狗，該看門狗可以是獨立硬件看門狗，即該類看門狗僅提供看門狗功能，但是一般都是QM等級，還有一類便是集成在PMIC內部的看門狗，該類看門狗一般都可以達到ASIL B或者ASIL D功能安全等級要求。

外部看門狗對于關鍵安全系統(tǒng)而言，一般都是必需的，從某種意義上來講，內部看門狗其實可有可無，外部看門狗才至關重要。

看門狗控制模式

在AUTOSAR架構中，針對Watchdog Driver而言，定義了看門狗控制模式存在如下三種模式：

Off Mode：表示看門狗關閉狀態(tài)，對于關鍵安全系統(tǒng)，一般不能將其切換至Off狀態(tài)，即一旦打開，將不能被關閉；

Slow Mode：表示看門狗的一個長時間喂狗窗口，該模式一般用于系統(tǒng)啟動初始化過程中；

Fast Mode：表示看門狗的正常喂狗窗口喂狗模式，該模式運用在系統(tǒng)正常運行的過程中。

看門狗喂狗時序

如下圖4所示為Watchdog初始化，觸發(fā)看門狗喂狗以及改變看門狗模式的的三類函數(shù)調用場景。

Watchdog初始化：通過EcuM模塊調用函數(shù)Wdg_Init來完成Watchdog的初始化配置；

觸發(fā)看門狗喂狗：通過WdgM模塊調用WdgIf模塊提供的函數(shù)WdgIf_SetTriggerCondition來觸發(fā)底層驅動進行喂狗動作；

改變看門狗模式：通過WdgM模塊調用WdgIf模塊提供的函數(shù)WdgIf_SetMode來實現(xiàn)看門狗模式的改變。

圖4 看門狗初始化，觸發(fā)看門狗以及設置看門狗模式時序圖

如下圖5為Wathdog 驅動與底層看門狗硬件交互的時序圖，從下圖可以看出WdgIf_SetTriggerCondition中會繼續(xù)調用Wdg驅動中函數(shù)Wdg_SetTriggerCondition來實現(xiàn)喂狗動作。

圖5 看門狗驅動與底層硬件看門狗交互時序關系圖

常見函數(shù)API與配置參數(shù)

為了便于大家能夠快速的對這個模塊的重點函數(shù)調用，有個較為清楚的了解，小T通過表格的方式進行了如下總結：

圖6 看門狗驅動模塊常用函數(shù)接口說明

圖7 看門狗驅動模塊常用配置參數(shù)說明

理解Watchdog If模塊

Watchdog If模塊功能描述

Watchdog If模塊全稱為Watchdog Interface接口，該接口作為底層Watchdog Driver的抽象，是為了實現(xiàn)底層硬件與軟件之間的解耦。

該模塊的基本功能僅僅作為底層驅動的抽象層來實現(xiàn)底層看門狗驅動與上層看門狗管理模塊的交互，底層看門狗驅動的特性，如窗口控制，時間周期等設置都不能通過Watchdog If模塊來完成。

如果超過一個看門狗驅動被上層Watchdog Manager進行管理，那么DeviceIndex將需要被檢查，如果出現(xiàn)錯誤，需要及時上報。

常見函數(shù)API與配置參數(shù)

為了便于大家能夠快速的對這個模塊的重點函數(shù)調用，有個較為清楚的了解，小T通過表格的方式進行了如下總結：

圖8 Watchdog If模塊常用函數(shù)說明

圖8 Watchdog If模塊常用配置參數(shù)說明

理解Watchdog Manager模塊

Watchdog Manager模塊工作原理

Watchdog Manager可以理解為一種應用層軟狗機制，該軟件機制監(jiān)控的對象被稱為“監(jiān)控實體”。其監(jiān)控方式可以分為如下三種：

Alive Supervision: 用于監(jiān)控周期性任務是否周期性運行；

Deadline Supervision：用于監(jiān)控事件型任務的運行時間是否超時；

logical supervision: 用于監(jiān)控任務的執(zhí)行時序是否正確；

通過在每個監(jiān)控實體中打上對應的Checkpoint，每一個監(jiān)控實體可以有一個或者多個Checkpoint，在一個監(jiān)控實體內部的Checkpoint及其轉換關系稱為內圖，如果是來自不同監(jiān)控實體的Checkpoint及其轉換關系則為外圖。

上述這三種監(jiān)控機制用于監(jiān)控每一個實體，每一個被監(jiān)控的實體可能會有其中一個或者多個甚至三個機制全部使能，這個取決于具體的需求?；谏鲜鋈N監(jiān)控機制的監(jiān)控結果，每一個監(jiān)控實體便可以計算得出，被稱為Local Status。

當每一個監(jiān)控實體的狀態(tài)得到確定，那么整個MCU的監(jiān)控結果便可以最終確定，這個最終確定的狀態(tài)被稱為Global Status。

Watchdog Manager具體工作流程：

S1：Watchdog Manager模塊負責通過Watchdog If以及Watchdog Driver來實現(xiàn)設置Watchdog Driver喂狗的觸發(fā)條件，該觸發(fā)條件就是通過Watchdog Manager的函數(shù)接口來重置Counter值；

S2：若Counter不為0，那么Watchdog Driver就會進行一次喂狗，同時將Counter值減一；

S3：若Counter值沒有被Watchdog Manager進行及時重置，那么就會減少至0，那么Watchdog Driver就會停止喂狗，從而看門狗就會觸發(fā)系統(tǒng)復位，否則繼續(xù)執(zhí)行S2；

值得注意的是如果觸發(fā)條件不滿足，沒法進行正常喂狗，那么存在兩種方式進行系統(tǒng)喂狗：

等待看門狗超時復位：停止喂狗，等待看門狗超時復位；

主動立即觸發(fā)系統(tǒng)復位：當Watchdog Manager發(fā)生錯誤時可以主動觸發(fā)系統(tǒng)復位；

上述兩種復位方式都是可以共存的，具體執(zhí)行哪個復位方式都可以按需執(zhí)行。

在使用Watchdog Manager時，Watchdog Driver初始化不能由Watchdog Manager來完成，而應該由EcuM模塊來完成，而Watchdog Manager初始化應該在OS開啟之后執(zhí)行。

Alive Supervision

如上所述，針對周期性任務的監(jiān)控實體，在給定的時間范圍內對應監(jiān)控實體執(zhí)行的次數(shù)是確定的，通過這個監(jiān)控機制可以用于檢測某些周期性任務運行太過頻繁或者過少。

在使用AliveSupervision過程中，有以下幾點需要注意：

對于一個監(jiān)控實體，采用Alive監(jiān)控機制，就不要超過1個checkpoit，當前僅支持一個Checkpoint。

根據(jù)如下四個參數(shù)進行調整使用來決定Alive Supervision如何進行監(jiān)控，如何有效。

Deadline Supervision

如上所述，針對非周期性任務的監(jiān)控實體，其監(jiān)控實體對應的兩個checkpoint之間的時間應該在一定范圍內，從而可以通過判斷兩個checkpoint之間的時間是否位于設定的最小值與最大值之間。

在使用Deadline Supervision過程中，有以下幾點需要注意：

該監(jiān)控機制只能監(jiān)控到延遲，無法檢測到超時，如End Checkpoint未執(zhí)行；

該監(jiān)控機制不支持嵌套，如start 1，start2， end2， end1；

如下圖為Deadline Supervision 邏輯圖，通過計算兩個Checkpoint的時間差值來得到是否滿足設定的要求。

Logic Supervision

如前所述，logic supervision則用于來實現(xiàn)程序流運行時序是否正確，這對于滿足功能安全的ECU而言至關重要，通過將實際運行過程中的checkpoint之間的切換關系是否滿足設定的checkpoint切換關系來進行判斷，如果不在設定的checkpoint關系之內，那么就會上報錯誤，如果均在checkpoint之內，那么則一切運行正常。

如下圖為Logic Supervision的拓撲結構，通過識別兩兩checkpoint之間的切換關系是否屬于靜態(tài)配置的切換關系Group內，來決定是否執(zhí)行的是正常的序列行為。

如下圖9所示，為整個Watchdog Manager模塊的運行機理：

圖9 Watchdog manager模塊作用機理

基于上述圖9，我們可以得出如下幾個重要的結論：

采用Alive Supervision的監(jiān)控實體，其判斷結果在WdgM_Mainfunction中得出；

采用Deadline Supervision或者Logical Supervision的監(jiān)控實體，其判斷結果則在函數(shù)WdgM_CheckpointReached中得出；

每個監(jiān)控實體均存在一個Local Status，該Local Status的最終結果將決定最終ECU的Global Status，因此有必要搞清楚WdgM的Local Status如何發(fā)生變化，如下圖10為Local Status狀態(tài)機：

圖10 Watchdog manager中Local Status變化狀態(tài)機/center> 通過上述圖10 ，我們可以得出如下幾個基本結論：

如圖中執(zhí)行序列10，在執(zhí)行完WdgM_Init函數(shù)后，便會將每個監(jiān)控實體的Local Status將會變成WDGM_LOCAL_STATUS_OK；

如圖中執(zhí)行序列11， 若在執(zhí)行WdgM_Init中，存在沒有被WdgMInitialMode參考的監(jiān)控實體，那么這些監(jiān)控實體的值將會被默認設置為WDGM_LOCAL_STATUS_DEACTIVATED；同時被WdgMInitialMode參考的監(jiān)控實體的WdgMInitialMode并沒有設置成WDGM_LOCAL_STATUS_OK，那么也會被設置成WDGM_LOCAL_STATUS_DEACTIVATED。

如果所有監(jiān)控實體的監(jiān)控結果都OK且監(jiān)控實體的Local Status都是WDGM_LOCAL_STATUS_OK，那么就會執(zhí)行序列1；

如果某監(jiān)控實體狀態(tài)為WDGM_LOCAL_STATUS_OK，但是其對應的Alive Supervision或者Deadline Supervision或者Logical supervision的結果為incorrect，那么狀態(tài)機就會執(zhí)行序列2；

由于監(jiān)控實體的Alive Supervision的結果允許存在錯誤門限值，因此若某監(jiān)控實體所有的Deadline Supervision或者Logical supervision的結果均為correct，但是存在某次Alive Supervision的結果錯誤但并沒有超出設定的錯誤門限值時，那么就會執(zhí)行序列3進入到WDGM_LOCAL_STATUS_FAILED。

若當前監(jiān)控實體(SE)的狀態(tài)處于WDGM_LOCAL_STATUS_FAILED狀態(tài)，除了Deadline Supervision或者Logical supervision的結果均為correct以外，但至少存在一次Alive Counter錯誤卻并未超過錯誤門限值，那么就會執(zhí)行序列4；

若SE Local Status == WDGM_LOCAL_STATUS_FAILED狀態(tài)，該SE的Alive Supervision均正確，且當前失敗的次數(shù)大于1，同時對應的Deadline Supervision或者Logical supervision的結果均為correct，那么就會繼續(xù)保持在WDGM_LOCAL_STATUS_FAILED狀態(tài)，不過會將錯誤次數(shù)減1，如序列4；

若SE Local Status == WDGM_LOCAL_STATUS_FAILED狀態(tài)，該SE的Alive Supervision均正確，且當前失敗的次數(shù)等于1，同時對應的Deadline Supervision或者Logical supervision的結果均為correct，那么就會在 WdgM_MainFunction中將狀態(tài)切換至WDGM_LOCAL_STATUS_OK狀態(tài)，同時將錯誤次數(shù)減小至0，如序列5；

若SE Local Status == WDGM_LOCAL_STATUS_FAILED狀態(tài)，該SE的Alive Supervision為incorrect，且當前失敗的次數(shù)大于其閾值，或者至少存在一個對應的Deadline Supervision或者Logical supervision的結果為incorrect，那么就會在 WdgM_MainFunction中將狀態(tài)切換至WDGM_LOCAL_STATUS_EXPIRED狀態(tài)，如序列6；

若SE Local Status == WDGM_LOCAL_STATUS_OK狀態(tài)，同時執(zhí)行了WdgM_SetMode切換狀態(tài)至OFF狀態(tài)，那么就會改變狀態(tài)機狀態(tài)為WDGM_LOCAL_STATUS_DEACTIVATED狀態(tài)，如序列7；

若SE Local Status == WDGM_LOCAL_STATUS_FAILED狀態(tài)，同時執(zhí)行了WdgM_SetMode切換狀態(tài)至抑制狀態(tài)，那么就會改變狀態(tài)機狀態(tài)為WDGM_LOCAL_STATUS_DEACTIVATED狀態(tài)，如序列8；

若SE Local Status == WDGM_LOCAL_STATUS_DEACTIVATED狀態(tài)，WdgM_CheckpointReached以及WdgM_MainFunction函數(shù)將不會啟動任何監(jiān)控作用，如序列8；

若SE Local Status == WDGM_LOCAL_STATUS_DEACTIVATED狀態(tài)，同時執(zhí)行了WdgM_SetMode切換狀態(tài)至激活狀態(tài)，那么就會改變狀態(tài)機狀態(tài)為WDGM_LOCAL_STATUS_OK狀態(tài)，如序列9；

在從其他狀態(tài)切換至WDGM_LOCAL_STATUS_EXPIRED狀態(tài)時，Watchdog Manager提供一定的時間保留機制能夠允許你做一些特別的操作，如設置看門狗模式或者寫入NVM數(shù)據(jù)，復位原因等。

講完了上述監(jiān)控實體的Local Status 狀態(tài)機變換條件，接下來我們來進一步了解下監(jiān)控實體的Global Status狀態(tài)機，該狀態(tài)機如下圖11所示：

圖10 Watchdog manager中Global Status變化狀態(tài)機

如上圖10所示，對于整個受監(jiān)控的軟件，Watchdog Manager僅會存在唯一的一個Global Status。該狀態(tài)機的變化具體規(guī)則如下：

如果執(zhí)行了WdgM_Init函數(shù)，那么Global Status == WDGM_GLOBAL_STATUS_OK，如序列13；

如果Global Status == WDGM_GLOBAL_STATUS_OK階段，執(zhí)行了函數(shù)WdgM_DeInit，那么就會導致狀態(tài)機切換：Global Status == WDGM_GLOBAL_STATUS_ DEACTIVATED，如序列14；

若Global Status == WDGM_GLOBAL_STATUS_OK，且所有SE的Local Status == WDGM_LOCAL_STATUS_OK或者WDGM_LOCAL_STATUS_DEACTIVATED，那么Global Status將保持不變，如序列1；

若Global Status == WDGM_GLOBAL_STATUS_OK，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_FAILED，且沒有SE的結果==WDGM_LOCAL_STATUS_EXPIRED，那么Global Status將會切換至WDGM_GLOBAL_STATUS_FAILED狀態(tài)，如序列2；

若Global Status == WDGM_GLOBAL_STATUS_OK，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_EXPIRED且WdgMExpiredSupervisionCycleTol設置大于0，那么Global Status將會切換至WDGM_GLOBAL_STATUS_EXPIRED狀態(tài)，如序列3；

若Global Status == WDGM_GLOBAL_STATUS_OK，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_EXPIRED且WdgMExpiredSupervisionCycleTol設置等于0，那么Global Status將會切換至WDGM_GLOBAL_STATUS_STOPPED狀態(tài)，如序列4；

若Global Status == WDGM_GLOBAL_STATUS_FAILED，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_FAILED且不存在等于WDGM_LOCAL_STATUS_EXPIRED的SE時，Global Status狀態(tài)將保持不變，如序列5；

若Global Status == WDGM_GLOBAL_STATUS_FAILED，且所有SE的== WDGM_LOCAL_STATUS_OK或者WDGM_LOCAL_STATUS_DEACTIVATED，那么Global Status將切換成WDGM_GLOBAL_STATUS_OK，如序列6；

若Global Status == WDGM_GLOBAL_STATUS_FAILED，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_EXPIRED且WdgMExpiredSupervisionCycleTol設置大于0，那么Global Status將切換成WDGM_GLOBAL_STATUS_EXPIRED，如序列7；

若Global Status == WDGM_GLOBAL_STATUS_FAILED，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_EXPIRED且WdgMExpiredSupervisionCycleTol設置等于0，那么Global Status將切換成WDGM_GLOBAL_STATUS_STOPPED，如序列8；

若Global Status == WDGM_LOCAL_STATUS_EXPIRED，且超時Counter計數(shù)小于WdgMExpiredSupervisionCycleTol設定的值，那么其狀態(tài)將保持不變，如序列9；

若Global Status == WDGM_LOCAL_STATUS_EXPIRED，且至少存在一個SE的計數(shù)大于WdgMExpiredSupervisionCycleTol，其狀態(tài)將切換成 WDGM_GLOBAL_STATUS_STOPPED，在這種狀態(tài)下，看門狗驅動將停止喂狗，等待看門狗超時復位，如序列10；

若Global Status == WDGM_GLOBAL_STATUS_STOPPED，其狀態(tài)將會一直保持不變，如序列11；

若執(zhí)行調用函數(shù) WdgIf_SetMode失敗，那么也會導致Global Status切換成WDGM_GLOBAL_STATUS_STOPPED狀態(tài)，如序列12。

常見函數(shù)API與配置參數(shù)

為了便于大家能夠快速的對這個模塊的重點函數(shù)調用，有個較為清楚的了解，小T通過表格的方式進行了如下總結：

Watchdog與功能安全關系

在ISO26262中，程序流監(jiān)控是其中最為重要的一項，通過程序流監(jiān)控可以發(fā)現(xiàn)軟件運行過程中可能違法設計意圖的錯誤，從而采取相應的措施，確保行車安全。

在AUTOSAR軟件架構中，程序流的監(jiān)控功能實現(xiàn)主要由Watchdog 協(xié)議棧來實現(xiàn)，自上而下包括WdgM模塊，WdgIf模塊以及Wdg驅動模塊，對于應用層而言，這三個模塊通過RTE給到應用層提供接口服務，由此來實現(xiàn)底層監(jiān)控應用層軟件的目的。

Watchdog使用實踐心得

通過EcuM模塊來完成看門狗初始化之后，剛開始設置的看門狗Counter初始值盡可能能夠Cover住Watchdog Driver初始化至Watchdog Manager初始化的時間，否則容易造成狗超時。

在OS shutdown之前Watchdog Manager去初始化，在去初始化過程中需要設置成較大的Timeout值，以確保能夠覆蓋住Watchdog Manager去初始化至系統(tǒng)power down或者再次reset的過程。

如果ECU支持休眠模式，如果在ECU休眠情況下看門狗仍保持在活躍狀態(tài)，那么就需要在EcuM模塊中來完成看門狗的喂狗操作。

在系統(tǒng)初始化以及休眠兩個階段應重點考慮看門狗是否會存在超時的可能，如果底層硬件都無法來得及喂狗，將會對系統(tǒng)造成重大影響。

審核編輯：湯梓紅