一、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、故障處理方式

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

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

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

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

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