前言

近年來，由于汽車技術的進步和各種組件的整合，汽車系統變得越來越復雜。隨著汽車新四化的變革，配備的功能和特性越來越多，讓汽車不再是傳統觀念里的汽車，而更加像一個“消費電子產品”，甚至像是一個“電動玩具”。

但這種智能化、電子化的趨勢在增加產品功能、滿足更多用戶需求的同時，也增加了汽車系統本身的復雜性。這種復雜性帶來了系統可靠性、維護和故障排除等方面的挑戰。消費者會希望汽車更加智能互通，就像我們的智能手機等其他消費電子一樣新穎酷炫。但相信消費者同時也希望汽車依然保持安全至上的產品屬性，不會像消費電子一樣動不動死機、卡屏或者變磚。

這種復雜的用戶需求，無疑是當下智能汽車發展的重要推動力。各大廠家的工程技術人員也開發出更加強大的監控、故障診斷、測試和維護策略，以確保這些復雜系統的最佳性能和可靠性。這也跟我們經常強調的功能安全所強關聯。這次我們就來看看其中兩個重要的方案：看門狗（Watchdog）和平臺健康管理（Platform Health Management）。

看門狗

看門狗的英語一般會說Watchdog Timer，雖然中文里往往省略了Timer的翻譯，但是看門狗本質上是一個計時器機制。

抽象地來看，看門狗就是一個系統的守護狗，它會一直監控著它的“主人”，確保“主人”不會思想跑飛。怎么監控呢？它會期待“主人”（按照定時器）定期地給它喂食，如果按時投喂，則一切如常。如果超時了還沒有被投喂，那看門狗可能會先吠叫幾聲，如果吠叫完還沒有反應，那可能看門狗還會極端地去“咬”醒主人。

用工程語言再來描述的話，看門狗就是系統中的一個組件，用于監控其他組件的運行是否可能出現故障。當檢測到可能的故障時，看門狗定時器系統會發出信號或啟動適當的跳轉指令，并根據當時的問題進行調整。信號或跳轉指令可直接或間接觸發其他合作的系統組件，從而解決問題。特別是在微控制器控制的設備中，經常可以看到看門狗的身影。這些看門狗定時器往往用來防止系統因軟件故障而失效，看門狗會在固定的時間間隔內告知系統是否仍在正常工作。

那這個機制具體可以怎么實現呢？我們來看看下圖的例子。

圖：外置看門狗的實現原理示意圖

圖左方是TPS3850芯片和MCU芯片的電路連接原理圖。TPS3850可以監控電壓和提供看門狗功能，這里我們只關注看門狗功能，對應“WDI”和“WDO”端口，也就是看門狗的輸入和輸出端口。上圖右方就是這兩個端口的信號示意圖。當MCU按照正常周期輸出高電平脈沖給WDI端口時，WDO端口就會穩定輸出高電平。但WDI超前或者延后輸出高電平脈沖時，就會觸發WDO輸出低電平，觸發MCU上的中斷。該中斷可以在MCU上觸發復位等操作。

當然，這個只是其中一種實現看門狗機制的例子。實際上我們可以通過不同的軟硬件來實現這個機制。比如我們可以做一個純軟件的計時器，來實現看門狗的功能，也可以用純硬件來實現這個功能。當然，軟硬件結合后，再細分不同的監控對象，用不同的方式喂狗，就可以豐富監控和響應效果。比如某些程序喂狗失敗就會重啟應用或者功能降級，關鍵程序喂狗失敗就會直接重啟系統等。

而按照是否采用外部的獨立看門狗芯片來區分，我們又常常會分為“內狗”和“外狗”。在汽車行業實際應用中，我們往往會同時采用多種類型的看門狗，比如同時采用內狗和外狗，來讓系統更加高效的同時更加魯棒。比如常見的英飛凌AURIX芯片，就針對每個CPU都有一個內置的看門狗，對整個AURIX芯片系統也有一個看門狗。這些都是內狗。同時，MCU也會往往由一個外部看門狗芯片（也常集成在電源管理芯片中）來監控MCU的狀態。

圖：外狗、內狗示意圖

平臺健康管理

平臺健康管理（Platform Health Management）則是AUTOSAR Adaptive Platform（AP）中一個重要的功能集群。它與執行管理（Execution Management）和狀態管理（State Management）共同協作，是AP中的功能安全基石。

在監控內容方面，PHM可以對監控實體的存活（Alive Supervision）、邏輯性（Logical Supervision）和死線（Deadline Supervision）進行監控。

存活監控可檢查受監控實體的運行頻率是否過高或者過低。

死線監控可檢查受監控實體中的步驟是否在Manifest中配置的最短和最長時間內執行。

邏輯監控可以檢查執行過程中的控制流是否與設計的控制流相匹配。

這三種類型的監控可以獨立使用，并基于被監控實體的檢查點報告執行。

在操作系統拉起AP平臺后，EM和SM就負責維護整個AP平臺的進程、線程管理了，包括啟動、終止和狀態切換等。除了可以用來監控AP平臺上的其他應用程序以外，PHM的一個關鍵任務就是監控EM和SM本身的狀態。由于EM和SM是AP平臺的關鍵基礎特性，在任何正常的系統狀態下，這兩個功能集群都應該運行。當PHM監控到EM和SM出現異常時，PHM就需要重啟整個機器（也就是重啟操作系統）了，因為此時常規的系統狀態切換和操作已經不可靠了。

圖6：PHM從EM、SM接口獲取信息的示意圖

看門狗與平臺健康管理的協同

看到這里，相信聰明的你也開始把看門狗和PHM兩者聯系起來了。沒錯，當PHM監控到EM和SM異常時，就需要對看門狗進行相應操作以恢復系統。如上圖左方所示，PHM和看門狗接口（Watchdog Interface）模塊的交互接口主要有兩個:

lAliveNotification：PHM會根據配置，周期性地調用該接口，通知看門狗接口模塊，PHM還正常工作著。

lFireWatchdogReaction：某些情況下，PHM監控到關鍵進程失效，比如EM和SM，PHM可以通過該接口觸發看門狗接口模塊，驅動硬件看門狗進行復位操作。

說到這里，我們就不得不重新提到整個Adaptive Platform和Classic Platform的最大差別：AP本質上是中間件，不包含操作系統和底層驅動，而CP是包含底層驅動和操作系統的。在這個背景下，AP平臺設計的PHM，其監控對象就是AP中間件及Adaptive Application （AA）。而PHM的故障響應策略也不是直接驅動硬件底層進行看門狗操作，而是留了接口，由外部的看門狗接口模塊（不屬于AP中間件）來去實現看門狗驅動和硬件看門狗的操作執行。

這與實際工程中AP和CP的應用環境也是一致對應的。CP通常跑在高度嵌入式的MCU中。MCU上一般也有芯片內部的硬件看門狗邏輯模塊。按照芯片開發CP軟件的時候，就能適配好內置看門狗驅動。而AP經常跑在復雜異構的SOC上，這些SOC往往并沒有內置硬件看門狗。

寫在最后

總的來說，PHM和看門狗關系密切，是保障智能汽車這個復雜系統能夠可靠安全地運行的關鍵手段。PHM監控應用程序和關鍵中間件平臺，主動維護系統健康。而看門狗則是持續守護系統的基石，在系統異常時，能夠充當守門員作為最后一關，觸發系統重啟等安全操作。PHM和看門狗的協同，在日益復雜智能的汽車系統中，既能提高系統總體效率，又能確保系統安全和可靠。在汽車消費者越來越把汽車當作“消費電子”的時代，我們從業者更應該時刻警惕：汽車終究是一個交通工具，汽車安全性是重中之重，不可或缺。

而作為汽車工程師，我們亦可緊跟趨勢，在使用AUTOSAR等架構減少重復開發的同時，專注于關鍵設計，例如AP平臺之上PHM需要監控哪些實體，在故障發生時配置哪些響應行為等。希望大家能利用好PHM和看門狗的工具箱，共同設計出既智能好玩又安全的汽車產品。

審核編輯：湯梓紅