01、什么是看門狗？

看門狗技術(shù)是20世紀(jì)80年代由美國半導(dǎo)體巨頭AMD公司首次提出，是一種專門用于檢測、記錄處理器運行狀況以及在異常情況下復(fù)位的一種技術(shù)，隨著技術(shù)的不斷的迭代，看門狗逐漸發(fā)展成一類專門的芯片，廣泛應(yīng)用于汽車、工業(yè)自動化、物聯(lián)網(wǎng)等領(lǐng)域。 ? 軟件會在執(zhí)行完特定指令后進(jìn)行喂狗，若在一定周期內(nèi)看門狗沒有收到來自軟件的喂狗信號，則認(rèn)為系統(tǒng)故障，會進(jìn)入中斷處理程序或強制系統(tǒng)復(fù)位。系統(tǒng)上電后根據(jù)不同的工作模式可以選擇使能看門狗，若看門狗被使能則計數(shù)器開始計數(shù)，如果在設(shè)定的時間內(nèi)沒有及時喂狗則會發(fā)生看門狗超時。通過寄存器對看門狗進(jìn)行基本設(shè)置，計數(shù)器計算狗叫時間，狗叫模塊決定看門狗超時后發(fā)出的中斷或復(fù)位方式。 看門狗發(fā)展至今，功能已經(jīng)發(fā)展的比較完善，所以已經(jīng)有很多比較詳細(xì)且角度不同的分類，例如按照種類分可以分為硬件看門狗和軟件看門狗；按照與單片機集成性可以分為內(nèi)部看門狗和外部看門狗； ?

? 02、TLF35584中集成的看門狗

以汽車產(chǎn)品中最通用的英飛凌的TLF35584芯片為例，該電源管理芯片通過了ISO26262的ASILD的認(rèn)證，并且集成了看門狗模塊，該看門狗模塊既屬于硬件看門狗，同時也屬于外部看門狗。由Window Watchdog和Functional Watchdog組成，（后面簡化成為WWD和FWD） Window Watchdog和Functional Watchdo

功能看門狗與窗口看門狗不同步，兩者完全獨立。

功能看門狗和窗口看門狗可以獨立激活和禁用。

看門狗的結(jié)果（有效或無效觸發(fā)）由相關(guān)看門狗故障計數(shù)器獨立監(jiān)控。

窗口看門狗的狀態(tài)為WWO，其值可能為“有效WWD 觸發(fā)”或“無效WWD 觸發(fā)”。

功能看門狗的狀態(tài)為FWO，其值可能為“有效FWD 觸發(fā)”或“無效FWD 觸發(fā)”。

兩個看門狗的設(shè)置對安全狀態(tài)控制的影響在安全狀態(tài)控制一章中進(jìn)行了描述，以便更好地理解。

03、Window Watchdog（WWD）

我們稱作窗口看門狗或時間看門狗，首先被監(jiān)控的控制器（MCU）必須在Open Window期間內(nèi)觸發(fā)（就是指喂狗操作），喂狗可以通過 WDI 引腳上的下降沿或通過 SPI 命令寫入寄存器 WWDSCMD，具體取決于配置。觸發(fā)后將終止“Open Window”?？撮T狗輸出指示 WWD 故障計數(shù)器的“有效”或“無效”WWD 觸發(fā)。 如果有效觸發(fā)，則啟動“Closed Window”。如果在“Open Window”期間沒有觸發(fā)或在“Closed Window”期間觸發(fā)，看門狗輸出指示“無效 WWD 觸發(fā)”到 WWD 失敗計數(shù)器，并啟動新的“Open Window”。 ?

1.WWD工作狀態(tài)圖

Window Watchdog State

“觸發(fā)”可以是發(fā)送到 WWDSCMD 寄存器的 SPI 命令，也可以是 WDI 引腳上的有效看門狗觸發(fā)

“Long open Window”中“No Trigger”被視為“無效WWD 觸發(fā)”，看門狗會再次打開一個“Long Open Window”

“Long open Window”內(nèi)的“觸發(fā)”被視為“有效 WWD 觸發(fā)”，看門狗關(guān)閉“Long open Window”并打開“Closed Window”

“CLosed Window”內(nèi)的“觸發(fā)”被視為“無效WWD觸發(fā)”

“Closed Window”結(jié)束后，“Closed Window”內(nèi)的“無觸發(fā)”會將看門狗移至“Open Window”。

“Open Window”內(nèi)的“觸發(fā)”被視為“有效WWD 觸發(fā)”，看門狗關(guān)閉“Open Window”并打開“Closed Window”

“Open Window”中的“無觸發(fā)”被視為“WWD 觸發(fā)無效”。

2.WDI引腳觸發(fā)WWD

看門狗輸入引腳 WDI 具有集成的下拉電流 IWDI ?？撮T狗輸入 WDI 可以在“Closed Window”內(nèi)或隨后的“Open Window”期間轉(zhuǎn)換為高電平。

WDI引腳 ?

WD的有效觸發(fā)信號

看門狗輸入 WDI 以TSAMT周期定期采樣。有效觸發(fā)信號是從VWDIV,高電平到VWDIV,低電平的下降沿。為了提高 WDI 輸入上的抗噪聲或毛刺的能力，有效觸發(fā)信號至少需要兩個高采樣點，然后是兩個低采樣點，通過測量低信號的第二個連續(xù)采樣點來考慮有效觸發(fā)。例如，如果引腳 WDI 處的觸發(fā)脈沖的前三個采樣（兩個高一個低）位于“關(guān)閉窗口”內(nèi)，并且僅在“打開窗口”中采集第四個采樣（第二個低采樣），則看門狗 輸出 WWO 將指示“有效 WWD 觸發(fā)”。 ?

WDI 觸發(fā)無效

在“Open Window”期間未檢測到觸發(fā)信號或在“Closed Window”期間檢測到觸發(fā)信號，均視為無效觸發(fā)?？撮T狗輸出 WDO 在“Open Window”期間無有效觸發(fā)后立即指示“無效觸發(fā)”，或者在“Closed Window”期間檢測到觸發(fā)信號后立即指示“無效觸發(fā)”。

WDI有效觸發(fā)和無效觸發(fā) ? 3.WWD正常工作——正確觸發(fā)

正確觸發(fā)

如果 ROT（監(jiān)控微控制器相關(guān)電壓）的復(fù)位輸出變高，則“Long Open Window”在 INIT 狀態(tài)下啟動。如果窗口看門狗在睡眠狀態(tài)下被停用，則第一個Open Window將從睡眠狀態(tài)轉(zhuǎn)換到喚醒狀態(tài)（由中斷指示）開始。第一個Open Window的時間取決于配置的周期時間，為 600 ms (WDCYC = 1) 或 60 ms (WDCYC = 0)。

在“Long Open Window”期間，預(yù)計會根據(jù)配置的觸發(fā)選擇有效觸發(fā) WWD?！伴LOpen Window”的最長時間是固定的，但一旦識別到“有效 WWD 觸發(fā)”，它就會終止。

窗口看門狗現(xiàn)在將進(jìn)入“Closed Window”。收到第一個有效觸發(fā)后，設(shè)備將被允許從 INIT 狀態(tài)移至 NORMAL 狀態(tài)或從 WAKE 狀態(tài)移至 NORMAL 狀態(tài)。

“Closed Window”具有固定的持續(xù)時間 tWD,CWt_{WD,CW} （可以通過SPI 命令確定）。它在有效觸發(fā)信號后立即啟動，關(guān)閉“Open Window”或“長Open Window”。在“Closed Window”期間不應(yīng)施加觸發(fā)信號。不會檢測到 WDI 引腳從低電平到高電平的轉(zhuǎn)換，也不會導(dǎo)致觸發(fā)事件。

有效的觸發(fā)信號立即終止“Open Window”，因此“Open Window”的時間是可變的，并且取決于微控制器安排觸發(fā)的時間。這被視為“有效 WWD 觸發(fā)”。

4.WWD異常工作——在“Long Open Window”未觸發(fā)

在Long Open Window未觸發(fā)

初始化超時和Long Open Window（LOW）具有相同的典型值。長度。通常這會導(dǎo)致初始化超時在低電平之前或同時完成，這將跳過中斷事件 (1)。盡管由于給定的精度，“Long Open Window”內(nèi)缺少有效觸發(fā)可能會在低電平結(jié)束后導(dǎo)致中斷事件，從而使窗口看門狗故障計數(shù)器增加 2。

INIT狀態(tài)定時器第一次超時。由于在 INIT 狀態(tài)期間未按預(yù)期接收到窗口看門狗的有效觸發(fā)，因此將發(fā)出所謂的“軟復(fù)位”：引腳 ROT 變?yōu)榱?，但后置穩(wěn)壓器的輸出電壓保持開啟狀態(tài)。附加信息：如果窗口看門狗在接下來的 INIT 階段的下一個“Long Open Window”內(nèi)未正確觸發(fā)，將發(fā)出“硬復(fù)位”，這意味著引腳 ROT 將變?yōu)榱?，并且輸出電壓?也被關(guān)閉。在 INIT 階段第三次無效觸發(fā)后，設(shè)備將進(jìn)入 FAILSAFE 狀態(tài)。

經(jīng)過上電復(fù)位延遲時間trd后，所謂的“軟復(fù)位”引腳ROT再次變高，看門狗打開一個“Long Open Window”，讓微控制器有機會觸發(fā)并同步到看門狗周期 。

有效觸發(fā)終止“Long Open Window”，這使得“Long Open Window”的持續(xù)時間可變并取決于觸發(fā)。這被視為“有效 WWD 觸發(fā)”并啟動“Closed Window”。在不發(fā)出中斷的情況下，窗口看門狗故障計數(shù)器將減 1。

接下來的“Closed Window”持續(xù)時間 tWD,CWt。在此時間內(nèi)觸發(fā)將被視為“無效WWD觸發(fā)”。

5.WWD異常工作——在“ Open Window”未觸發(fā)

在Open Window未觸發(fā)

“Open Window”內(nèi)缺少有效觸發(fā)，導(dǎo)致窗口結(jié)束后出現(xiàn)“無效 WWD 觸發(fā)”。該事件由中斷指示，窗口看門狗故障計數(shù)器增加 2。

檢測到“無效 WWD 觸發(fā)”后，看門狗將啟動一個持續(xù)時間為 tWD,CWt_{WD,CW} 的新“Open Window”，以使微控制器有機會觸發(fā)并同步到看門狗周期。

有效觸發(fā)終止“Open Window”，這使得“Open Window”的持續(xù)時間可變并取決于觸發(fā)。這被視為“有效 WWD 觸發(fā)”并啟動“Closed Window”。在不發(fā)出中斷的情況下，窗口看門狗故障計數(shù)器將減 1。

如果“Open Window”內(nèi)出現(xiàn)多次“無效 WWD 觸發(fā)”，窗口看門狗故障計數(shù)器將再次增加 2，直到達(dá)到配置的閾值。在這種情況下，將發(fā)出重置命令。

接下來的“Closed Window”持續(xù)時間 tWD,CWt_{WD,CW} 。在此時間內(nèi)觸發(fā)將被視為“無效WWD觸發(fā)”。

引腳 ROT 的行為取決于 ΣWWO 的值。在上面的例子中，假設(shè)無效觸發(fā)不會導(dǎo)致超過閾值ΣWWO。 ? ? 6.WWD異常工作——在初始化之后的“Closed Window”中錯誤的觸發(fā)

“Closed Window”期間的觸發(fā)被指示為“無效WWD觸發(fā)”。該事件由中斷指示，并且窗口看門狗故障計數(shù)器增加 2。

“Closed Window”將因“WWD 觸發(fā)無效”而關(guān)閉。最初它會持續(xù)時間 tWD,CWt_{WD,CW} 。錯誤觸發(fā)終止“Closed Window”并啟動“Open Window”，以使微處理器有機會同步到窗口看門狗周期。

在此“Open Window”內(nèi)預(yù)計會發(fā)生有效觸發(fā)。有效的觸發(fā)會終止“Open Window”，這使得“Open Window”的持續(xù)時間可變并取決于觸發(fā)。這被視為“有效 WWD 觸發(fā)”并啟動“Closed Window”。在不發(fā)出中斷的情況下，窗口看門狗故障計數(shù)器將減 1。

接下來的“Closed Window”持續(xù)時間 tWD,CWt_{WD,CW} 。在此時間內(nèi)觸發(fā)將被視為“無效WWD觸發(fā)”。

引腳 ROT 的行為取決于 ΣWWO 的值。在上面的例子中，假設(shè)無效觸發(fā)不會導(dǎo)致超過閾值ΣWWO。 ? ? 7.WWD異常工作——在穩(wěn)態(tài)“Closed Window”錯誤的觸發(fā)

在Close Window中錯誤的觸發(fā)

“Closed Window”期間的觸發(fā)被指示為“無效WWD觸發(fā)”。該事件由中斷指示，并且窗口看門狗故障計數(shù)器增加 2。

“Closed Window”將因“WWD 觸發(fā)無效”而關(guān)閉。最初它會持續(xù)時間 tWD,CWt_{WD,CW} 。錯誤觸發(fā)終止“Closed Window”并啟動“Open Window”，以使微處理器有機會同步到窗口看門狗周期。

在此“Open Window”內(nèi)預(yù)計會發(fā)生有效觸發(fā)。有效的觸發(fā)會終止“Open Window”，這使得“Open Window”的持續(xù)時間可變并取決于觸發(fā)。這被視為“有效 WWD 觸發(fā)”并啟動“Closed Window”。在不發(fā)出中斷的情況下，窗口看門狗故障計數(shù)器將減 1。

接下來的“Closed Window”持續(xù)時間 tWD,CWt_{WD,CW} 。在此時間內(nèi)觸發(fā)將被視為“無效WWD觸發(fā)”。

引腳 ROT 的行為取決于 ΣWWO 的值。在上面的例子中，假設(shè)無效觸發(fā)不會導(dǎo)致超過閾值ΣWWO。

04、Functional Watchdog（FWD） ? 我們稱作功能看門狗或問答看門狗。在穩(wěn)定狀態(tài)下，會生成一個問題（從表中取出），同時心跳計數(shù)器從零開始計數(shù)。心跳計數(shù)器開始計數(shù)，直到心跳周期結(jié)束。心跳周期的持續(xù)時間可以通過 SPI 命令進(jìn)行設(shè)置和調(diào)整。 問題由 4 bits組成，預(yù)期答案由 4 個回復(fù)組成，每個回復(fù)為 8 位。這四個回復(fù)應(yīng)在心跳周期結(jié)束之前發(fā)送。最后回復(fù)應(yīng)寫入同步回復(fù)寄存器以重置心跳計數(shù)器。

Functional Watchdog的問題與回復(fù) 功能看門狗輸出 FWO 是一個內(nèi)部信號：它連接到 FWD 故障計數(shù)器。功能看門狗 FWO 輸出的值為“有效 FWD 觸發(fā)”或“無效 FWD 觸發(fā)”。 ? ? 1.FWD工作流程圖

FWD工作流程圖 步驟如下：

首先判斷FWD是否使能；如果未使能，停止并清空心跳計數(shù)器值；如果使能，請?zhí)敛襟E2；

開啟心跳計數(shù)器，并生成初始化問題；

設(shè)置response byte number為3，準(zhǔn)備接受第一個回復(fù)；

等待回復(fù)值；

判斷心跳計數(shù)器是否超時，如果超時，重置心跳計數(shù)器，F(xiàn)WD故障計數(shù)器加2，請?zhí)敛襟E4；如果未超時，請?zhí)敛襟E6；

判斷新的回復(fù)值是否收到？如果未收到，請?zhí)敛襟E4；如果收到了，請?zhí)敛襟E7；

判斷是否為最后一個回復(fù)？如果不是，將response byte number減1，請?zhí)敛襟E4；如果是，請?zhí)敛襟E8；

判斷是否同步了回復(fù)？如果未同步，請?zhí)敛襟E9；如果同步了，重置心跳計數(shù)器，也請?zhí)敛襟E9；

判斷回復(fù)是否正確？如果不正確，請?zhí)敛襟E10；如果正確，F(xiàn)WD故障計數(shù)器減1，生成新的問題，請?zhí)敛襟E3；

判斷是否同步了回復(fù)？如果未同步，請?zhí)敛襟E3；如果同步了FWD故障計數(shù)器加2，也請?zhí)敛襟E3。

2.FWD正常工作——正確觸發(fā)

正確觸發(fā)模式 步驟如下：

生成一個新問題，同時心跳計數(shù)器開始計數(shù)（假設(shè)之前發(fā)生過“有效 FWD 觸發(fā)”）

收到正確的回復(fù)（RESP3）

收到正確的回復(fù)（RESP2）

收到正確回復(fù)（RESP1）

收到正確的同步回復(fù)（RESP0）。所有回復(fù)均正確，回復(fù)順序正確，并且在心跳計數(shù)器溢出之前收到最后一個同步回復(fù)。心跳計數(shù)器將被重置（設(shè)置為零）。這被視為“有效 FWD 觸發(fā)”，功能看門狗錯誤計數(shù)器 ΣFWO 減 1（如果功能看門狗錯誤計數(shù)器值大于零）

生成一個新問題，同時心跳計數(shù)器開始計數(shù)

3.FWD異常工作——同步丟失

同步丟失 步驟如下：

生成一個新問題，同時心跳計數(shù)器開始計數(shù)（假設(shè)之前發(fā)生過“有效 FWD 觸發(fā)”）

收到正確的回復(fù)（RESP3）

收到正確的回復(fù)（RESP2）

收到正確回復(fù)（RESP1）

接收到正確的回復(fù)（RESP0），但未同步（寫入錯誤的寄存器）。到目前為止，所有回復(fù)都是正確的，回復(fù)順序是正確的，并且在心跳計數(shù)器溢出發(fā)生之前收到了最后一個不同步的回復(fù)。心跳計數(shù)器不會被重置并繼續(xù)計數(shù)。這被視為“有效 FWD 觸發(fā)”，功能看門狗錯誤計數(shù)器 ΣFWO 減 1（如果功能看門狗錯誤計數(shù)器值大于零）。生成了一個新問題

心跳計數(shù)器仍在計數(shù)，等待新問題的回復(fù)。心跳計數(shù)器將到期并發(fā)生溢出。這被視為“無效 FWD 觸發(fā)”。這功能看門狗錯誤計數(shù)器 ΣFWO 加 2。心跳計數(shù)器復(fù)位

心跳計數(shù)器開始計數(shù)。，不會產(chǎn)生新問題

4.FWD異常工作——回答錯誤

回答錯誤 步驟如下：

生成一個新問題，同時心跳計數(shù)器開始計數(shù)（假設(shè)之前發(fā)生過“有效 FWD 觸發(fā)”）

收到正確的回復(fù)（RESP3）

收到正確的回復(fù)（RESP2）

收到錯誤回復(fù)(RESP1)

收到正確的回復(fù)（RESP0）， 心跳計數(shù)器將被重置（設(shè)置為零）， 完整的答案是不正確的。這被視為“無效 FWD 觸發(fā)”。功能看門狗錯誤計數(shù)器 ΣFWO 加 2。心跳計數(shù)器復(fù)位

沒有生成新問題，但心跳計數(shù)器開始計數(shù)

注意：如果將Resp2和Resp1混合在一起，則將兩個回復(fù)視為不正確的，則必須按正確的順序發(fā)送回復(fù)。 ? ? 5.FWD異常工作——回復(fù)丟失

回復(fù)丟失 步驟如下：

生成一個新問題，同時心跳計數(shù)器開始計數(shù)（假設(shè)之前發(fā)生過“有效 FWD 觸發(fā)”）

收到正確的回復(fù)（RESP3）

收到正確的回復(fù)（RESP2）

缺少回復(fù)(RESP1)

收到正確的回復(fù)（RESP0）。因此，由于缺少回復(fù)（在此示例中為 RESP1），最后一個回復(fù)不是最后一個回復(fù)，而是倒數(shù)第二個回復(fù)。功能看門狗將等待所有四個回復(fù)被寫入，而心跳計數(shù)器繼續(xù)計數(shù)。所有四個回復(fù)沒有固定時間，但必須在心跳計數(shù)器到期之前以正確的順序發(fā)送

由于缺少回復(fù)RESP1，完整答案不正確。雖然最后的回復(fù)是同步的，但是心跳計數(shù)器不會被重置并繼續(xù)計數(shù)，直到發(fā)生溢出。這被視為“無效 FWD 觸發(fā)”。功能看門狗錯誤計數(shù)器 ΣFWO 加 2。心跳計數(shù)器復(fù)位

不再生成新問題，心跳計數(shù)器開始計數(shù)

05、為什么需要Watch Dog？ ? 1.功能安全標(biāo)準(zhǔn)軟件部分要求 首先在功能安全標(biāo)準(zhǔn)第6章，7.4.12中提到，應(yīng)使用看門狗進(jìn)行軟件的時間監(jiān)控和程序流監(jiān)控。

ISO26262標(biāo)準(zhǔn)第6章 ? 2.功能安全標(biāo)準(zhǔn)硬件部分要求 在第5章的附錄中，也提到了不同看門狗的功能和診斷覆蓋率

看門狗的診斷覆蓋率

功能安全標(biāo)準(zhǔn) ? 標(biāo)準(zhǔn)中分別介紹幾種看門狗的目標(biāo)和功能描述，我在這里歸納總結(jié)一下在ISO26262中，看門狗作為安全機制的一些用法和要求

看門狗的作用 ? ? 06、如何使用看門狗？ ? 1.功能安全對看門狗的要求 標(biāo)準(zhǔn)并沒有明確給出不同的ASIL等級如何使用看門狗，下面是個人根據(jù)自身的項目經(jīng)驗，給出的一些建議，僅供參考。

看門狗監(jiān)控的使用建議 2.內(nèi)部看門狗VS外部看門狗

內(nèi)部看門狗與外部看門狗 3.看門狗監(jiān)控機制的作用

看門狗監(jiān)控機制 ? ? 07、看門狗Autosar架構(gòu) ? 1.靜態(tài)架構(gòu) 首先看一下Autosar中看門狗功能的靜態(tài)架構(gòu)，看門狗在Autosar中屬于非常標(biāo)準(zhǔn)的功能，架構(gòu)層面也比較清晰。

Autosar看門狗靜態(tài)架構(gòu) ? Autosar的看門狗結(jié)構(gòu)主要有： 內(nèi)部看門狗：WatchDog Manager，WatchDog Interface, WatchDog Driver，On Chip WatchDog 外部看門狗：WatchDog Manager，WatchDog Interface, SPI，Off Chip WatchDog ? 分別對應(yīng)Autosar中的服務(wù)層，ECU抽象層，控制器抽象層（MCAL）和硬件

Autosar的看門狗模塊 值得注意的是內(nèi)部看門狗可以通過WatchDog Driver去訪問，比較簡單；而外部看門狗需要使用SPI通信或者其他方式進(jìn)行訪問，相比內(nèi)部看門狗復(fù)雜一點。 被監(jiān)控實體（Supervised Entity）：就是你想要監(jiān)控的對象，它可以是一個SWC、運行實體、BSW模塊或者復(fù)雜驅(qū)動。 檢查點（Check Point）：在被監(jiān)控實體中的重要的位置插入一些點叫做檢查點，后面所有的計算和檢查都基于這些檢查點。 ? ? 2.動態(tài)架構(gòu) 如下圖所示為Watchdog初始化，觸發(fā)看門狗喂狗以及改變看門狗模式的的三類函數(shù)調(diào)用場景。

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

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

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

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

看門狗喂狗過程2 ? ? 08、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ū)動。 以英飛凌TLF35584為例，需要SPI驅(qū)動

TLF35584芯片看門狗系統(tǒng)框圖 在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)正常運行的過程中。

09、WatchDog Interface ? Watchdog If模塊全稱為Watchdog Interface接口，該接口作為底層Watchdog Driver的抽象，是為了實現(xiàn)底層硬件與軟件之間的解耦。 該模塊的基本功能僅僅作為底層驅(qū)動的抽象層來實現(xiàn)底層看門狗驅(qū)動與上層看門狗管理模塊的交互，底層看門狗驅(qū)動的特性，如窗口控制，時間周期等設(shè)置都不能通過Watchdog If模塊來完成。
如果超過一個看門狗驅(qū)動被上層Watchdog Manager進(jìn)行管理，那么DeviceIndex將需要被檢查，如果出現(xiàn)錯誤，需要及時上報。 Watchdog If模塊整體來說，配置比較簡單 函數(shù)：

WdgIf_SetMode：設(shè)置看門狗模式

WdgIf_SetTriggerCondition：出發(fā)喂狗操作

WdgIf_GetVersionInfo：獲取看門狗模塊的Autosar版本信息

參數(shù)：

WdgIfVersionInfoApi:是否使能Autosar版本讀取功能

WdgIfDevErrorDetect:手機否使能模塊錯誤Det錯誤檢測功能 TRUE使能， FALSE禁用

WdgIfDeviceIndex:支持多個看門狗驅(qū)動的索引

WdgIfDriverRef:當(dāng)前看門狗的索引

WatchDog Interface參數(shù) ? ? 10、WatchDog Manager ? 1.基本工作過程 當(dāng)Supervised Entities執(zhí)行時，每當(dāng)運行到某一Checkpoint時，會調(diào)用對應(yīng)的WdgM接口上報狀態(tài)。一個Supervised Entity可以擁有一個或者多個Checkpoint，它們在Supervised Entity內(nèi)部的關(guān)聯(lián)信息構(gòu)成了一個Graph，也可以叫它Internal Graph，不同Supervised Entities之間的Checkpoints的關(guān)聯(lián)則構(gòu)成了External Graph。每一種WdgM模式下都可以有多個External Graph，在一個Graph中，可以有多個Initial Checkpoint或者多個Final Checkpoints，這種情況下，無論從哪一個Initial Checkpoint開始這個執(zhí)行流程都可以，同樣，無論在哪個Final Checkpoint結(jié)束此次執(zhí)行流程也是可以的。 一個Supervised Entity可以同時設(shè)置多種Supervision機制，基于每一種機制返回的狀態(tài)，可以計算出當(dāng)前Supervised Entity的狀態(tài)，也即Local Status。當(dāng)每一個Supervised Entity的狀態(tài)都得到的時候，就能計算出整個MCU的狀態(tài)了，也即Global Supervision Status。每一種Supervision功能都會返回狀態(tài)列表，代表正確或者不正確，最后對于每一個Supervised Entity來說會有三個狀態(tài)，Alive Supervision狀態(tài)，Deadline Supervision狀態(tài)，Logical Supervision狀態(tài)。然后計算出本地狀態(tài)，也即綠色框所示。最后是紅色框所示的全局狀態(tài)。執(zhí)行WdgM_CheckpointReached()函數(shù)，會更新Deadline Supervision和Logical Supervison的狀態(tài)，執(zhí)行WdgM_Mainfunction()更新Alive Supevision的狀態(tài)。

整體工作過程 ? 2.本地狀態(tài)更新

Local Supervision Status

路徑1：如果三種監(jiān)控狀態(tài)都返回的是正確，并且最近一次記錄的本地狀態(tài)是OK，那么本地狀態(tài)將停留在OK狀態(tài)

路徑2：如果上次記錄的本地狀態(tài)是OK，滿足任一條件時，本地狀態(tài)為EXPIRED：至少一個Alive Supervision返回的是incorrect，且容忍度（Tolerance）設(shè)置為0 至少一個Dealine Supervision或者Logical Supervision返回的狀態(tài)時incorrect

路徑3：如果上次記錄的本地狀態(tài)是OK，同時滿足以下兩個條件時，本地狀態(tài)為FAILED：至少一個Alive Supervision返回的是incorrect，且容忍度（Tolerance）大于0 所有的Dealine Supervision或者Logical Supervision返回的狀態(tài)都是correct.

路徑4：如果上次記錄的本地狀態(tài)是FAILED，同時滿足以下兩個條件時，本地狀態(tài)保持FAILED：至少一個Alive Supervision返回的是incorrect，且失敗次數(shù)小于容忍度（Tolerance） 所有的Dealine Supervision或者Logical Supervision返回的狀態(tài)都是correct. 或者 至少一個Alive Supervision返回的是incorrect，且錯誤次數(shù)大于1 所有的Dealine Supervision或者Logical Supervision返回的狀態(tài)都是correct.

路徑5：如果上次記錄的本地狀態(tài)是FAILED，同時滿足以下兩個條件時，本地狀態(tài)為OK：所有的Alive Supervision返回的是correct，且錯誤計數(shù)器等于1 所有的Dealine Supervision或者Logical Supervision返回的狀態(tài)都是correct.

路徑6：如果上次記錄的本地狀態(tài)是FAILED，滿足以下任一條件時，本地狀態(tài)為EXPIRED：至少一個Alive Supervision返回的是incorrect，且失敗次數(shù)等于于容忍度（Tolerance） 至少一個Dealine Supervision或者Logical Supervision返回的狀態(tài)時incorrect。

路徑7：如果激活后禁用，則設(shè)置為DEACTIVATED狀態(tài)。

路徑8：如果禁用后，Wdg函數(shù)沒有監(jiān)控任何SE，則維持為DEACTIVATED狀態(tài)。

路徑9：如果禁用后激活，則切換到OK狀態(tài)。

路徑10：WdgM初始化后，在初始化模式激活的SE的本地狀態(tài)將處在OK狀態(tài)。

路徑11：如果不在初始化模式激活，SE的本地狀態(tài)將處在DEACTIVATED狀態(tài)。

路徑12：如果上一次狀態(tài)是FAILED，禁用后切換到DEACTIVATED狀態(tài)。

3.全局狀態(tài)更新

全局狀態(tài)更新

路徑1：上次記錄的全局狀態(tài)為OK，當(dāng)前SE的本地狀態(tài)為OK或者DEACTIVATED，全局狀態(tài)保持在OK。

上次記錄的全局狀態(tài)為OK，當(dāng)前SE至少有一個本地狀態(tài)是FAILED，且沒有SE狀態(tài)是EXPIRED，全局狀態(tài)為FAILED。

上次記錄的全局狀態(tài)為OK，當(dāng)前至少有一個SE的本地狀態(tài)是EXPIRED，且未超過閾值，全局狀態(tài)為EXPIRED。

上次記錄的全局狀態(tài)為OK，當(dāng)前至少有一個SE的本地狀態(tài)是EXPIRED，且超過閾值，全局狀態(tài)為STOPPED。

上次記錄的全局狀態(tài)為FAILED，當(dāng)前至少有一個SE的本地狀態(tài)是FAILED，且沒有EXPIRED，全局狀態(tài)將保持在FAILED。

上次記錄的全局狀態(tài)為FAILED，當(dāng)前所有的SE的本地狀態(tài)是OK或者DEACTIVATED，全局狀態(tài)為OK。

上次記錄的全局狀態(tài)為FAILED，當(dāng)前至少有一個SE的本地狀態(tài)是EXPIRED，且未超過閾值，全局狀態(tài)為EXPIRED。

上次記錄的全局狀態(tài)為FAILED，當(dāng)前至少有一個SE的本地狀態(tài)是EXPIRED，且超過閾值，全局狀態(tài)為STOPPED

上次記錄的全局狀態(tài)為EXPIRED，當(dāng)前至少有一個SE的本地狀態(tài)是EXPIRED，且未超過閾值，全局狀態(tài)將保持在EXPIRED

上次記錄的全局狀態(tài)為EXPIRED，當(dāng)前至少有一個SE的本地狀態(tài)是EXPIRED，且超過閾值，全局狀態(tài)為STOPPED

上次記錄的全局狀態(tài)為STOPPED，全局狀態(tài)將保持在STOPPED

如果調(diào)用WdgIf_SetMode失敗，全局狀態(tài)為STOPPED

路徑13：當(dāng)WdgM初始化函數(shù)調(diào)用之后，全局狀態(tài)為OK

路徑14：如果上一次全局狀態(tài)為OK，成功調(diào)用WdgM_DeInit之后，全局狀態(tài)為DEACTIVATED。

路徑15：如果上一次全局狀態(tài)為FAILED，成功調(diào)用WdgM_DeInit之后，全局狀態(tài)為DEACTIVATED。

路徑16：如果上一次全局狀態(tài)為EXPIRED，成功調(diào)用WdgM_DeInit之后，全局狀態(tài)為DEACTIVATED。

路徑17：如果上一次全局狀態(tài)為STOPPED，成功調(diào)用WdgM_DeInit之后，全局狀態(tài)為DEACTIVATED。

路徑18：WdgM的全局狀態(tài)，初始化狀態(tài)為DEACTIVATED。

11、WatchDog服務(wù)工作原理 ? 1.Alive Supervision 1.參數(shù)配置 如下圖所示為Alive Supervision的監(jiān)控方式，可以看到對于監(jiān)控實體SE3中只有有一個Checkpoint3-1

Alive Supervision參數(shù) 在上圖中我們看到配置Alive Supervision，需要配置下如下四個基本參數(shù)：

WdgMExpectedAliveIndications：在給定的時間內(nèi)某監(jiān)控實體SE調(diào)用WdgM_CheckpointReached函數(shù)的次數(shù)，即Expected值；

WdgMMaxMargin：調(diào)用上述函數(shù)的次數(shù)的增加的偏移值，即實際值=Expected值+WdgMMaxMargin；

WdgMMinMargin：調(diào)用上述函數(shù)的次數(shù)的減少的偏移值，即實際值=Expected值-WdgMMinMargin；

WdgMSupervisionReferenceCycle：基于WdgM_Mainfunction調(diào)用函數(shù)周期的次數(shù)作為監(jiān)控參考周期。

2.工作原理

調(diào)用一次WdgM_CheckpointReached --> 發(fā)送一次Alive indication --> Alive Counter+1

通過 WdgMSupervisionReferenceCycle 設(shè)定 WdgMSupervisionCycle，應(yīng)該是它的整數(shù)倍

Expected-MinMargin < WdgM_CheckpointReached調(diào)用次數(shù) < Expected+MaxMargin，如果超出此范圍，報監(jiān)控錯誤狀態(tài)，即會影響到該SE的Local Status狀態(tài)。

為了避免出現(xiàn)有時間設(shè)定的WdgM_CheckpointReached函數(shù)調(diào)用次數(shù)為0或者1時，可能會出現(xiàn)即使該監(jiān)控實體不再執(zhí)行時，也會出現(xiàn)滿足許可調(diào)用次數(shù)的情況，一般設(shè)計建議選取WdgM主函數(shù)周期及監(jiān)控實體SE所在任務(wù)周期兩者之間的最小公倍數(shù)來設(shè)置監(jiān)控參考周期，確保每個監(jiān)控參考周期內(nèi)的WdgM_CheckpointReached()函數(shù)調(diào)用次數(shù)都是固定值，此時，上下偏差MinMargin和MaxMargin均設(shè)為0即可。

2.Deadline Supervision Deadline supervison主要用于非周期性的監(jiān)控實體SE，該類監(jiān)控實體往往都是事件型進(jìn)行觸發(fā)，觸發(fā)之后的監(jiān)控實體SE執(zhí)行的時間不能過長，同時也不能過短，這個SE的執(zhí)行時長就需要通過相應(yīng)的閾值進(jìn)行限定，從而來監(jiān)控其運行狀態(tài)是否滿足設(shè)計要求。 ? 1.參數(shù)配置 對于每一個SE的Deadline Supervision，兩個Checkpoint時必須需要進(jìn)行配置的，因為Deadline Supervision就是針對兩個Checkpoint之間的Transition執(zhí)行時間進(jìn)行監(jiān)控，即針對監(jiān)控實體SE執(zhí)行的動態(tài)行為進(jìn)行監(jiān)控。 如下圖所示為SE4的Deadline Supervision監(jiān)控方式，存在一個Start Checkpoint4-1以及End Checkpoint4-2. ? 基本參數(shù)如下：

WdgMDeadlineMin：兩個Checkpoint的Transition經(jīng)歷的時間最小值；

WdgMDeadlineMax：兩個Checkpoint的Transition經(jīng)歷的時間最大值；

如下圖所示為SE4的Deadline Supervision監(jiān)控方式，存在一個Start Checkpoint4-1以及End Checkpoint4-2

Deadline Supervision監(jiān)控1 下圖所示為某個SE實體同時存在多個Checkpoint的場景，在該類場景下，彼此之間不存在多大關(guān)聯(lián)，僅在于相鄰Checkpoint之間的執(zhí)行時間的測量。值得注意的是該類監(jiān)控的SE中不同Checkpoint不允許存在嵌套行為，如CP Start1, CP Start2, CP End2, CP End1。

Deadline Supervision監(jiān)控2 ? 2.工作原理

對于此類監(jiān)控模式，必須有兩種Start Checkpoint以及End Checkpoint兩類 Start Checkpoint --> 通過參數(shù) WdgMDeadlineStartRef 設(shè)定 End Checkpoint --> 通過參數(shù) WdgMDeadlineEndRef 設(shè)定

需要使用OS Counter去計算兩個Checkpoint之間的時間間隔

為了確定WdgM_CheckpointReached調(diào)用時的時間戳以及兩個Checkpoint之間Transition的時間，那么調(diào)用的函數(shù)WdgM_CheckpointReached中需要使用OS功能計算兩個Checkpoint之間的時間差距；

通過兩個Checkpoint之間Transition所經(jīng)歷的OS tick時間，并與配置的時間參數(shù)WdgMDeadlineMin以及WdgMDeadlineMax進(jìn)行比較，如果超過限值，則報出該監(jiān)控實體Deadline Supervision錯誤

3.Logical Supervision ? 1.配置過程 對于每一個Logic Supervision，每個Checkpoint之間的Transition便組成了Graph，這些Graph便抽象出了代碼邏輯的執(zhí)行時序流，如下圖所示為一個代碼正常執(zhí)行的程序時序流：

Autosar中程序流監(jiān)控示例 如上圖的7個Checkpoint，其簡化模型如下圖所示：

程序流監(jiān)控 上圖中描述了程序執(zhí)行可能的路徑，每個路徑都通過Checkpoint來進(jìn)行設(shè)定，那么便得到了上面所有的可能性，這些Checkpoint的Transition關(guān)系需要在配置中進(jìn)行體現(xiàn)。 ? 2.工作原理

當(dāng)程序運行至Checkpoint處，則調(diào)用WdgM_CheckpointReached()函數(shù)；

在該函數(shù)體內(nèi)會記錄上一次的Checkpoint Id以及兩個Checkpoint之間的Transition Id，其中Transition Id根據(jù)相鄰兩Checkpoint計算得到，若相鄰Checkpoint之間的Transition不是預(yù)期的Transition，那么就會報出該監(jiān)控實體Logic Supervision的狀態(tài)錯誤。

審核編輯：黃飛

?