正文

Watchdog基本功能

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

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

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

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

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

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

硬件看門狗

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

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

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

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

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

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

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

GPIO喂狗硬件看門狗：

IIC喂狗硬件看門狗：

SPI喂狗硬件看門狗：

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

軟件看門狗

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

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

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

圖2 軟狗與硬狗層級關(guān)系圖

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

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

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

AUTOSAR Watchdog協(xié)議棧介紹

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

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

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

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

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

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

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

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

理解Watchdog Driver模塊

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

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

內(nèi)部看門狗

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

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

外部看門狗

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

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

看門狗控制模式

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

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

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

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

看門狗喂狗時序

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

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

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

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

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

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

圖5 看門狗驅(qū)動與底層硬件看門狗交互時序關(guān)系圖

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

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

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

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

理解Watchdog If模塊

Watchdog If模塊功能描述

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

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

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

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

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

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

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

理解Watchdog Manager模塊

Watchdog Manager模塊工作原理

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

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

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

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

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

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

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

Watchdog Manager具體工作流程：

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

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

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

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

等待看門狗超時復(fù)位：停止喂狗，等待看門狗超時復(fù)位；

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

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

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

Alive Supervision

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

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

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

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

Deadline Supervision

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

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

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

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

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

Logic Supervision

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

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

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

圖9 Watchdog manager模塊作用機理

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

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

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

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

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

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

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

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

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

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

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

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

若SE Local Status == WDGM_LOCAL_STATUS_FAILED狀態(tài)，該SE的Alive Supervision均正確，且當(dāng)前失敗的次數(shù)等于1，同時對應(yīng)的Deadline Supervision或者Logical supervision的結(jié)果均為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，且當(dāng)前失敗的次數(shù)大于其閾值，或者至少存在一個對應(yīng)的Deadline Supervision或者Logical supervision的結(jié)果為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提供一定的時間保留機制能夠允許你做一些特別的操作，如設(shè)置看門狗模式或者寫入NVM數(shù)據(jù)，復(fù)位原因等。

講完了上述監(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，那么就會導(dǎo)致狀態(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的結(jié)果==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設(shè)置大于0，那么Global Status將會切換至WDGM_GLOBAL_STATUS_EXPIRED狀態(tài)，如序列3；

若Global Status == WDGM_GLOBAL_STATUS_OK，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_EXPIRED且WdgMExpiredSupervisionCycleTol設(shè)置等于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設(shè)置大于0，那么Global Status將切換成WDGM_GLOBAL_STATUS_EXPIRED，如序列7；

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

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

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

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

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

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

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

Watchdog與功能安全關(guān)系

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

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

Watchdog使用實踐心得

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

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

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

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

審核編輯：湯梓紅