一文帶你全面瞭解功能安全軟體監控方案

引言：功能安全標準（ISO26262 Part6）提到了用於錯誤探測的安全機制，其中就有程式流監控，如圖1所示；本文主要探討在AUTOSAR CP以及AP的場景下，怎麼實現程式流監控。

圖1 ISO26262 Part6

一、 CP 場景下的程式流監控

CP 場景下執行程式流監控的工作棧如圖2所示，包含軟體部分以及硬體部分。硬體部分就是通常所指的“硬體看門狗”，其本質是個定時器，初始階段會被設定一個定時值，稱為“timeout”。硬體看門狗被使能工作之後，便會開始計時，當超過時間閾值，“timeout”沒有被重置（通常重置時間閾值的操作被稱為“餵狗”），硬體看門狗便會復位MCU，進入安全狀態。

圖2 CP場景下的程式監控工作流

程式監控以及“餵狗操作”需要軟體部分的參與，軟體堆疊參考的是AUTOSAR CP架構，包含三個部分：WdgM、WdgIf以及Wdg Driver：

WdgM 負責對軟體進行監控，如果程式執行正確，則WdgM呼叫WdgIf提供的介面進行“餵狗”，WdgIf進一步呼叫Wdg Driver提供的介面進行“餵狗”，而最終的“餵狗”操作實際由Wdg Driver完成。

如果WdgM監控到程式執行錯誤，則會引發相應的故障處理措施：通常是停止餵狗或者將硬體看門狗的定時值置為0，引發看門狗的立即復位。接下來，對此三個軟體模組展開詳細說明。

1、WdgM 模組

WdgM 模組的作用是監控軟體是否正常執行，如果軟體正常執行，則WdgM呼叫WdgIf模組提供的介面進行餵狗；如果軟體執行中出現錯誤，則執行相應的錯誤處理，主要包括：透過RTE將錯誤通知給軟體，讓其執行恢復處理、將錯誤報告給DEM（Diagnostic Event Manager）模組、停止餵狗、將timeout設定為0，MCU立即重置或發出中斷訊號。

相應術語解釋

（1）SE：Supervised Entities ，監控實體

一種軟體實體，包括在WdgM的監控之下。每個受監控的實體只有一個識別符號。監控實體表示軟體元件或基礎軟體模組中的檢查點集合。在軟體元件或基礎軟體模組中可能有零個、一個或多個受監控的實體

監控實體和AUTOSAR中的架構模組之間沒有固定的關係，即SW-Cs、CDDs、RTE、BSW模組，但通常情況下，一個監督實體可以代表一個SW-C、一個BSW模組或CDD中的一個可執行物件

（2）CP：Checkpoint，檢查點

被監控實體中的一個點，在那裡活動被報告給WdgM

1）三種監控

WdgM 監控程式是否正常執行主要包括三種型別：

• Alive supervision ：程式是否週期執行
• Deadline supervision ：程式執行時間是否正確
• Logical supervision ：程式的執行邏輯是否正確

2）本地狀態和全域性狀態

本地狀態表示的是WdgM監控的單個SE的程式執行狀態，主要包含以下幾種：

• 狀態一：OK： 監控的SE未出現三種監控錯誤
• 狀態二：FAILED： 監控的 SE 出現 Alive 錯誤，且錯誤沒有超過 Alive 錯誤容忍值；同時， SE 沒有出現 Deadline 和 Logical 錯誤
• 狀態三：EXPIRED： 監控的 SE 出現 Deadline 或 Logical 錯誤，或者出現 Alive 錯誤並且 Alive 錯誤次數超出容忍值
• 狀態四：DEACTIVATED： SE 程式流監控沒有使能

圖3 本地狀態轉移關係

圖4 本地狀態轉移情況說明

全域性狀態表示的是WdgM監控的所有SE的狀態彙總，主要包含以下幾種：

• 狀態一：DEACTIVATED： 全域性狀態的初始值
• 狀態二：OK： 所有 SE 的狀態都為 OK 或者 DEACTIVATED
• 狀態三：FAILED： 至少一個 SE 的狀態為 FAILED 且沒有 SE 的狀態為 EXPIRED
• 狀態四：EXPIRED： 至少一個 SE 的狀態為 EXPIRED 且次數沒有超過監控錯誤容忍度值
• 狀態五： STOPPED： 至少一個 SE 的狀態為 EXPIRED 且次數超過監控錯誤容忍度值

圖5 全域性狀態轉移關係

圖6 全域性狀態轉移情況說明

3）WdgM 函式介面

圖 7 初始化WdgM模組流程圖

圖8 WdgM_MainFunction與WdgM_CheckpointReached互動

2、WdgIf模組

WdgIf模組的功能是為WdgM與看門狗驅動的互動提供函式介面。

3、Wdg Driver模組

Wdg Driver模組的功能是與看門狗硬體通訊，負責實際的餵狗操作。

二、AP 場景下的程式流監控

AP場景下實現程式流監控如圖9所示，也包含軟體部分和硬體部分。軟體部分主要是AUTOSAR-AP協議棧的PHM、SM、EM軟體模組，硬體部分則是硬體看門狗。

AP 場景進行程式流監控的相關術語、本地狀態和全域性狀態、狀態之間的轉移關係和CP場景下的差不多，本文不再贅述。有區別的主要是執行程式流監控的軟體模組和故障處理方式，接下來主要介紹這兩方面的內容。

圖9 AP場景下的程式監控工作流

1、AP軟體模組

AP 中和程式流監控相關的主要軟體模組是PHM、SM以及EM，具體來說，PHM負責執行具體的程式流監控，並基於監控的結果決定和其它模組的互動方式；SM負責狀態管理；EM根據SM的狀態切換請求執行具體的狀態切換。

2、 故障處理方式

程式執行出現問題，存在三條故障處理鏈路。

鏈路一

PHM 監控到程式流出現問題，PHM報告給SM模組，SM根據註冊的相應故障處理程式進行處理，包括停止出錯的應用程式；重啟出錯的應用程式以及重啟平臺；

鏈路二

如果SM超時沒有將錯誤處理的結果返回給PHM，PHM則直接將故障上報給EM，EM處理也分三種不同的級別：停止應用程式、重啟應用程式以及重啟平臺；

鏈路三

如果EM出錯，沒有及時返回故障處理的結果，則PHM通知硬體看門狗復位整個平臺。

三、程式流監控總結

程式流監控的目的是避免程式在執行邏輯以及執行時序上出現非預期行為。程式流監控由軟體來實現相應的監控邏輯，具體到CP以及AP端，採用的軟體模組會有所不同，兩者相同的是都會採用硬體看門狗復位的方式來處理故障。

為了滿足功能安全的要求，僅僅瞭解不同監控軟體模組的功能以及硬體看門狗是不夠的，還需要結合具體的系統設計（例如故障處理時間間隔 Fault Handling Time Interval ，FHTI）來正確設定不同的軟硬體引數，達到更優的程式流監控效果。

經緯恆潤功能安全團隊成立於 2008 年，系國內較早從事功能安全技術研究的團隊。作為功能安全、預期功能安全國家標準委員會成員，經緯恆潤的研發流程、生產流程已透過功能安全開發過程認證，功能安全開發過程達到 ASIL-D ，相關產品已成功服務於近百家國內外整車及零部件企業。

經緯恆潤功能安全軟體團隊可提供功能安全軟體開發技術諮詢服務，包括功能安全軟體階段流程/產品諮詢、L2監控演算法開發整合和L3安全機制（安全通訊、隔離、監控、執行和晶片AOU）的開發整合，控制器覆蓋動力域、底盤域、智駕域和車身域等。

未來，經緯恆潤將緊跟行業發展趨勢和市場需求，結合自身汽車電子產品研發和國內外諮詢實踐，一如既往地堅持自主創新道路，為智慧汽車安全保駕護航。