正文

Watchdog基本功能

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

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

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

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

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

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

硬件看門狗

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

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

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

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

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

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

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

GPIO喂狗硬件看門狗：

IIC喂狗硬件看門狗：

SPI喂狗硬件看門狗：

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

軟件看門狗

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

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

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

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

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

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

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

AUTOSAR Watchdog協議棧介紹

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

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

圖3 AUTOSAR架構下的Watchdog協議棧

如上圖3所示，在AUTOSAR架構下，Watchdog協議?？梢苑譃槿缦氯齻€軟件模塊：

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

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

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

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

理解Watchdog Driver模塊

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

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

內部看門狗

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

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

外部看門狗

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

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

看門狗控制模式

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

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

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

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

看門狗喂狗時序

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

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

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

改變看門狗模式：通過WdgM模塊調用WdgIf模塊提供的函數WdgIf_SetMode來實現看門狗模式的改變。

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

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

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

常見函數API與配置參數

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

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

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

理解Watchdog If模塊

Watchdog If模塊功能描述

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

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

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

常見函數API與配置參數

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

圖8 Watchdog If模塊常用函數說明

圖8 Watchdog If模塊常用配置參數說明

理解Watchdog Manager模塊

Watchdog Manager模塊工作原理

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

Alive Supervision: 用于監控周期性任務是否周期性運行；

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

logical supervision: 用于監控任務的執行時序是否正確；

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

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

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

Watchdog Manager具體工作流程：

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

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

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

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

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

主動立即觸發系統復位：當Watchdog Manager發生錯誤時可以主動觸發系統復位；

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

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

Alive Supervision

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

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

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

根據如下四個參數進行調整使用來決定Alive Supervision如何進行監控，如何有效。

Deadline Supervision

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

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

該監控機制只能監控到延遲，無法檢測到超時，如End Checkpoint未執行；

該監控機制不支持嵌套，如start 1，start2， end2， end1；

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

Logic Supervision

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

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

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

圖9 Watchdog manager模塊作用機理

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

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

采用Deadline Supervision或者Logical Supervision的監控實體，其判斷結果則在函數WdgM_CheckpointReached中得出；

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

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

如圖中執行序列10，在執行完WdgM_Init函數后，便會將每個監控實體的Local Status將會變成WDGM_LOCAL_STATUS_OK；

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

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

如果某監控實體狀態為WDGM_LOCAL_STATUS_OK，但是其對應的Alive Supervision或者Deadline Supervision或者Logical supervision的結果為incorrect，那么狀態機就會執行序列2；

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

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

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

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

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

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

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

若SE Local Status == WDGM_LOCAL_STATUS_DEACTIVATED狀態，WdgM_CheckpointReached以及WdgM_MainFunction函數將不會啟動任何監控作用，如序列8；

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

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

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

圖10 Watchdog manager中Global Status變化狀態機

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

如果執行了WdgM_Init函數，那么Global Status == WDGM_GLOBAL_STATUS_OK，如序列13；

如果Global Status == WDGM_GLOBAL_STATUS_OK階段，執行了函數WdgM_DeInit，那么就會導致狀態機切換：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狀態，如序列2；

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

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

若Global Status == WDGM_GLOBAL_STATUS_FAILED，至少存在一個SE的Local Status == WDGM_LOCAL_STATUS_FAILED且不存在等于WDGM_LOCAL_STATUS_EXPIRED的SE時，Global Status狀態將保持不變，如序列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計數小于WdgMExpiredSupervisionCycleTol設定的值，那么其狀態將保持不變，如序列9；

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

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

若執行調用函數 WdgIf_SetMode失敗，那么也會導致Global Status切換成WDGM_GLOBAL_STATUS_STOPPED狀態，如序列12。

常見函數API與配置參數

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

Watchdog與功能安全關系

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

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

Watchdog使用實踐心得

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

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

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

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

審核編輯：湯梓紅