智能汽車功能安全方案：看門狗和平臺健康管理

前言

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

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

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

看門狗

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

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

用工程語言再來描述的話，看門狗就是系統(tǒng)中的一個組件，用于監(jiān)控其他組件的運行是否可能出現(xiàn)故障。當檢測到可能的故障時，看門狗定時器系統(tǒng)會發(fā)出信號或啟動適當?shù)奶D(zhuǎn)指令，并根據(jù)當時的問題進行調(diào)整。信號或跳轉(zhuǎn)指令可直接或間接觸發(fā)其他合作的系統(tǒng)組件，從而解決問題。特別是在微控制器控制的設備中，經(jīng)?？梢钥吹娇撮T狗的身影。這些看門狗定時器往往用來防止系統(tǒng)因軟件故障而失效，看門狗會在固定的時間間隔內(nèi)告知系統(tǒng)是否仍在正常工作。

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

圖：外置看門狗的實現(xiàn)原理示意圖

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

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

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

圖：外狗、內(nèi)狗示意圖

平臺健康管理

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

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

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

死線監(jiān)控可檢查受監(jiān)控實體中的步驟是否在Manifest中配置的最短和最長時間內(nèi)執(zhí)行。

邏輯監(jiān)控可以檢查執(zhí)行過程中的控制流是否與設計的控制流相匹配。

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

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

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

看門狗與平臺健康管理的協(xié)同

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

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

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

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

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

寫在最后

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

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

審核編輯：湯梓紅