看門狗在嵌入式系統中的作用是個什么？

點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

看門狗技術是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