基于ISO26262混合ASIL系統(tǒng)設(shè)計應(yīng)用研究

謝凌云

(上海汽車變速器有限公司， 上海 201800)

0 引言

隨著汽車電動化、智能化和網(wǎng)聯(lián)化的推進，汽車儼然正在從一個傳統(tǒng)的代步工具過渡為一個行走的智能終端。電驅(qū)控制、輔助駕駛、智能座艙和域控制器的開發(fā)成為汽車行業(yè)爭相競逐的風向標，這些功能的問世無不需要強大的軟硬件支持，“軟件定義汽車”的時代正悄然到來。隨著這些技術(shù)的復雜性和軟件內(nèi)容的增加，隨之而帶來的是各種系統(tǒng)性失效和硬件隨機失效的可能性，導致汽車功能失效的環(huán)節(jié)也從機械和電子逐步轉(zhuǎn)變?yōu)楦嗟能浖栴}，如何解決汽車安全問題成為邁入“軟件定義汽車”新時代需要去反復思考的新問題。

道路車輛功能安全標準正是以解決汽車開發(fā)過程中的安全問題為目的而制定的，其中規(guī)范的第六部分對于軟件層面的描述強調(diào)了用軟件分區(qū)實現(xiàn)軟件組件間免于干擾[1]：要求一個軟件分區(qū)內(nèi)的任務(wù)彼此之間不能免于干擾；一個軟件分區(qū)不能改變其他軟件分區(qū)的代碼和數(shù)據(jù)，也不能控制其他軟件分區(qū)的非共享資源；一個軟件分區(qū)從共享資源獲取的服務(wù)不能被另一個軟件分區(qū)影響。

總的來說，在AUTOSAR架構(gòu)下開展對軟件組件間免于干擾設(shè)計的研究有重要的應(yīng)用價值和意義，是確保車輛軟件安全可靠的有效途徑。

1 軟件分區(qū)設(shè)計

如果對初始安全要求的ASIL分解導致將分解后的要求分配給預(yù)期功能及相關(guān)安全機制，則相關(guān)安全機制宜被賦予分解后的最高ASIL等級[2]，也就是說按照汽車安全完整性等級要求，如果一個功能按照ASIL D等級開發(fā)，要使整個系統(tǒng)都達到ASIL D要求，其他不需要這么高等級的功能模塊也需要按照最高等級要求開發(fā)，這會大大增加開發(fā)時間和成本。為解決以上提到的“ASIL等級提升效應(yīng)”問題，功能安全標準允許通過軟件分區(qū)的形式來實現(xiàn)不同安全等級的軟件組件之間的隔離和共存。

符合AUTOSAR標準的軟件提供了軟件分區(qū)的應(yīng)用，操作系統(tǒng)OS提供的分區(qū)由任務(wù)、中斷、報警器、定時器、調(diào)度表和鉤子函數(shù)等構(gòu)成。本文在Vector提供的MICROSAR軟件包的基礎(chǔ)上，基于主控芯片英飛凌TriCore277設(shè)計的混合ASIL系統(tǒng)如圖1所示，每個核都包含一個非信任和一個受信任的分區(qū)：非信任的分區(qū)運行在用戶模式下，運行時受訪問存儲和OS API等限制；受信任的分區(qū)運行在特權(quán)模式下，運行時可以訪問所有內(nèi)存區(qū)域和OS API等。

圖1 混合ASIL系統(tǒng)分區(qū)設(shè)計

2 免于干擾實現(xiàn)

軟件分區(qū)的設(shè)計是實現(xiàn)免于干擾需求的前提架構(gòu)，具體落實到軟件實現(xiàn)，包含內(nèi)存保護、時序保護和通訊保護等方面。

2.1 內(nèi)存保護

合理的軟件分區(qū)設(shè)計，可以抑制不同安全等級軟件組件之間的交互影響，內(nèi)存越界保護是實現(xiàn)軟件模塊之間邊界保護的重要途徑，主要使用微控制器內(nèi)存保護單元(Memory Protect Unit，MPU)對內(nèi)存區(qū)域的訪問進行限制。

英飛凌TriCore277主控芯片的每一個核都擁有16個數(shù)據(jù)保護單元用于規(guī)定數(shù)據(jù)的讀寫訪問權(quán)限和8個代碼保護單元用于規(guī)定代碼指令集的操作權(quán)限。同時擁有四個保護集(Protection Set，PS)，保護集搜集了該保護區(qū)域的讀/寫/執(zhí)行權(quán)限，分區(qū)切換過程中通過選擇不同的保護集從而實現(xiàn)快速切換訪問權(quán)限的功能。

在MICROSAR軟件平臺的基礎(chǔ)上，將OS的伸縮性等級配置為SC3，使其開啟內(nèi)存保護功能，通過配置多個Memory Region來實現(xiàn)分區(qū)之間的內(nèi)存保護。如圖2所示，每個Memory Region可配置的選項包含起始地址、終止地址、訪問權(quán)限、所屬保護集ID、所屬內(nèi)存和所屬分區(qū)等。

圖2 MICROSAR內(nèi)存區(qū)域配置

如果未配置所屬分區(qū)，該內(nèi)存區(qū)域被認為是靜態(tài)的，反之則是動態(tài)的。靜態(tài)MPU區(qū)域在系統(tǒng)啟動時就被設(shè)定好了，在OS運行過程中不再重新設(shè)置，通常用于多核訪問權(quán)限的配置；動態(tài)MPU區(qū)域在OS運行過程中會隨著分區(qū)的切換動態(tài)設(shè)置。

除了用戶配置的區(qū)域保護外，同時MICROSAR軟件對于任務(wù)或者中斷棧的溢出保護也采用了MPU機制，在棧頂會留有MPU可識別的最小地址長度，該棧的使用者沒有寫入權(quán)限，當系統(tǒng)檢測到該區(qū)域有數(shù)據(jù)寫入，會觸發(fā)MPU保護，根據(jù)用戶需求選擇Shutdown OS或者進入安全模式。

軟件設(shè)計的混合ASIL系統(tǒng)內(nèi)存保護按照如下表1方式配置，在兼顧系統(tǒng)易用的角度出發(fā)，重點對軟件組件間的RAM數(shù)據(jù)交互進行保護。

表1 內(nèi)存保護單元訪問權(quán)限配置

2.2 時序保護

車輛功能安全規(guī)范要求對于高安全等級的軟件實體需要實施相應(yīng)的時序保護。關(guān)于時間限制，每個軟件分區(qū)中執(zhí)行的軟件要素可考慮如下所列的故障影響[3]：

* 執(zhí)行阻塞；

* 死鎖；

* 活鎖；

* 執(zhí)行時間的不正確分配；

* 軟件要素間的不正確同步。

AUTOSAR中對運行實體時序的保護通過程序流監(jiān)控機制實現(xiàn)，包括監(jiān)控執(zhí)行時序和時間間隔兩個方面。該監(jiān)控機制的實現(xiàn)由軟件看門狗模塊和硬件看門狗配合完成，當看門狗監(jiān)測到運行實體中任何不符合預(yù)期的行為將觸發(fā)看門狗復位，讓系統(tǒng)回歸到正確的執(zhí)行路徑，保證系統(tǒng)處于安全模式下。本文描述的實現(xiàn)方式應(yīng)用于TriCore277+TLF35584的芯片組合。

根據(jù)前面提到的分區(qū)設(shè)計，高安全等級的軟件組件分布于每個核，為支持多核運行實體的監(jiān)控，并做到每個核互不干擾，每一個核都會有單獨的看門狗管理模塊負責時序監(jiān)控，并給出是否滿足喂狗的條件，由GPT觸發(fā)的定時中斷會根據(jù)喂狗條件來決定是否喂狗操作。將喂狗操作放在中斷執(zhí)行是因為中斷優(yōu)先級高于OS任務(wù)，以防止OS任務(wù)搶占機制影響喂狗觸發(fā)時機，導致提前或延遲喂狗，這種情況多發(fā)于系統(tǒng)啟動過程中。

AUTOSAR軟件對于喂狗條件的判定，提供了程序流保護機制(Program Flow Supervision，PFS)，它包含Alive Supervision、Deadline Supervision和Program Flow三種檢查方式。監(jiān)控機制通過檢查點(Checkpoint，CP)來標記軟件執(zhí)行位置，通過這些檢查點的執(zhí)行來獲取軟件執(zhí)行次序和執(zhí)行時間。

(1) Alive Supervision

用于監(jiān)控周期處理函數(shù)的執(zhí)行頻率，在周期處理函數(shù)中插入一個檢查點，程序在檢查點位置會通知看門狗管理程序周期函數(shù)已執(zhí)行，以表征程序處于激活狀態(tài)。該方式可以識別軟件的執(zhí)行阻塞、死鎖、活鎖，保證關(guān)鍵信號的周期獲取或關(guān)鍵算法的周期運行。

(2) Deadline Supervision

用于監(jiān)控兩個檢查點之間的運行時間是否符合預(yù)期，可以在軟件兩個狀態(tài)點插入檢查點，看門狗程序可以獲取檢查點到達的時間，從而得到程序片段執(zhí)行時間。該方式可以識別軟件執(zhí)行時間的不正確分配，對于執(zhí)行時間的考量，可以檢測出系統(tǒng)不易察覺的隨機或者不規(guī)律的跳動。

(3) Program Flow

用于監(jiān)控多個檢查點的執(zhí)行順序是否符合預(yù)期，可以在關(guān)鍵算法插入多個檢查點，看門狗管理程序通過獲取檢查點到達的順序，從而判斷程序是否符合預(yù)期狀態(tài)運行。該方式可以識別軟件要素間的不正確同步。

2.3 通信保護

同樣在混合ASIL系統(tǒng)中，對于高安全等級的軟件實體需要實施相應(yīng)的通信保護機制，與程序流監(jiān)控類似，需要在程序運行過程中檢測出可能的失效狀態(tài)，并及時做出相應(yīng)的后處理，以遏制因信號質(zhì)量差導致問題的進一步蔓延，將系統(tǒng)始終控制在安全狀態(tài)下。

(1)故障來源

通信故障來源于硬件和軟件兩個層面，硬件產(chǎn)生的隨機故障通常來自電氣過載、老化或受外部條件的影響。由硬件引起的通信故障主要包含以下三種失效方式[4]：

* 硬件通信網(wǎng)絡(luò)失效；

* 通信網(wǎng)絡(luò)存在電磁干擾；

* 發(fā)生在上下文切換或者多核通信間的芯片內(nèi)核故障。

而軟件產(chǎn)生的通信故障大部分是有跡可循的，但有部分隱藏的錯誤需要在特定的條件下才能觸發(fā)，在軟件測試無法完全覆蓋的情況下，采取恰當?shù)耐ㄐ疟Ｗo措施來識別錯誤的發(fā)生是非常有必要的。參照AUTOSAR標準開發(fā)的軟件通信故障主要由以下四個方面引起[4]：

* RTE通信故障；

* COM模塊引起的故障；

* 通信網(wǎng)絡(luò)協(xié)議棧引起的故障；

* IOC或OS引起的故障。

(2)錯誤類型

關(guān)于信息交換，針對每個發(fā)送方或接收方，可考慮如下所列各故障的原因或故障的影響[1]：

* 信息重復；

* 信息丟失；

* 信息延遲;

* 信息插入；

* 信息偽裝或信息的不正確尋址；

* 信息次序不正確

* 信息損壞；

* 從發(fā)送方傳送到多個接收方信息不對稱；

* 發(fā)送方發(fā)送的信息只能被部分接收方接受；

* 通信信道阻塞。

而AUTOSAR端到端(End-to-End，E2E)的保護機制正是針對以上通訊錯誤類型而設(shè)計的。

(3)E2E通信保護機制

E2E機制通過發(fā)送和接受計數(shù)器來識別信息重復、丟失、插入、次序不正確和阻塞；通過某幾個遲滯用途的計數(shù)器來識別信息丟失、延遲和阻塞；通過數(shù)據(jù)標識符和CRC來識別偽裝或信息的不正確尋址和插入；通過CRC來識別信息損壞和信息的不對稱等。

以應(yīng)用E2E Profile01保護非信任分區(qū)和信任分區(qū)軟件組件間的RTE通信為例，發(fā)送端保護機制如圖3所示，發(fā)送方可參照如下方式實現(xiàn)數(shù)據(jù)保護。

圖3 發(fā)送方端到端保護

① 運行實體依據(jù)軟件邏輯更新待發(fā)送的數(shù)據(jù)；

② 調(diào)用E2E_P01Protect接口保護數(shù)據(jù)，E2E庫會根據(jù)用戶配置更新待發(fā)送的數(shù)據(jù)；

③ 通過調(diào)用RTE接口將新的數(shù)據(jù)發(fā)送出去。

接收端保護機制如圖4所示，接受方可參照如下方式實現(xiàn)數(shù)據(jù)檢查。

圖4 接受方端到端保護

① 運行實體通過調(diào)用RTE接口獲取數(shù)據(jù)；

② 調(diào)用E2E_P01Check接口，檢查接受到的數(shù)據(jù)，E2E庫會根據(jù)用戶配置檢查數(shù)據(jù)的有效性，并返回檢查狀態(tài)；

③ 軟件根據(jù)獲取到的狀態(tài)執(zhí)行不同的邏輯策略，不同的失效狀態(tài)會觸發(fā)對應(yīng)的失效后處理，有效的數(shù)據(jù)才允許參與到后續(xù)的軟件策略里，從而保證系統(tǒng)的安全。

3 測試和驗證

基于以上系統(tǒng)設(shè)計，將測試程序燒寫到控制板上，配合PLS軟件調(diào)試設(shè)備分別完成了MPU、PFS和E2E等測試。

3.1 MPU內(nèi)存保護

測試示例如圖5所示，非信任分區(qū)中QM等級的運行實體在Tlib_En_Cpu1Mpu為真時，有訪問可信分區(qū)ASIL D軟件模塊變量Tlib_Ct_Cpu1Trust的風險。如果此類問題發(fā)生在車輛行進過程中，重要的扭矩或轉(zhuǎn)速信號被非法篡改，將可能導致嚴重的行車安全。

圖5 MPU測試示例

調(diào)試上位機UDE使能測試條件Tlib_En_Cpu1Mpu為真時，低安全等級的運行實體嘗試對變量Tlib_Ct_Cpu1Trust寫操作，觸發(fā)MPU例外保護，回調(diào)Shutdown_Hook函數(shù)，在該函數(shù)中可執(zhí)行相應(yīng)后處理，以保證系統(tǒng)安全。

圖6 MPU故障注入后數(shù)據(jù)

3.2 PFS時序保護

(1)Alive Supervision

圖7為Alive Supervision的測試示例，軟件配置不允許測試檢查點在監(jiān)督周期運行次數(shù)超過兩次，否則將認為軟件邏輯存在潛在風險。

圖7 Alive Supervision測試示例

圖8和圖9分別是故障注入前后的數(shù)據(jù)，設(shè)置Tlib_Ct_Wdg0Alive為2，檢查點將連續(xù)運行兩次，WdgM識別到故障，會將喂狗條件Wdg_30_Sbc_TrgCnd_conditionFlag置為不滿足，從而會中斷對TLF35584的喂狗操作，觸發(fā)復位機制。

圖8 Alive Supervision故障注入前數(shù)據(jù)

圖9 Alive Supervision故障輸入后數(shù)據(jù)

(2)Deadline Supervision

圖10為Deadline Supervision的測試示例，軟件配置不允許測試檢查點CP0到CP1的運行時間超過10 ms，否則系統(tǒng)會認為邏輯執(zhí)行時間超過預(yù)期，觸發(fā)看門狗保護。

圖10 Deadline Supervision測試示例

圖11和圖12分別是故障注入前后數(shù)據(jù)，故障注入后，觸發(fā)了看門狗保護。

圖11 Deadline Supervision故障注入前數(shù)據(jù)

圖12 Deadline Supervision故障注入后數(shù)據(jù)

(3)Program Flow

圖13為Program Flow的測試示例，軟件邏輯執(zhí)行順序配置如下，通過Tlib_En_Wdg1Switch切換檢查點，Tlib_En_Wdg1Inhibit抑制CP2的運行。

圖13 Program Flow測試示例

注入故障，將Tlib_En_Wdg1Inhibit置為1，WdgM識別到不符合預(yù)期的運行邏輯，將觸發(fā)看門狗保護，見圖14和圖15故障注入前后數(shù)據(jù)。Program Flow保護可以有效地監(jiān)督邏輯時序，屬于功能安全高推薦使用的機制之一。

圖14 Program Flow故障注入前數(shù)據(jù)

圖15 Program Flow故障注入后數(shù)據(jù)

3.3 E2E通信保護

根據(jù)2.3章節(jié)設(shè)計的測試示例如下，將保護可信分區(qū)從非信任分區(qū)獲取數(shù)據(jù)的可靠性。

圖16 E2E測試示例

高安全等級的軟件組件需要獲取低等級的變量Tlib_Num_E2E，該數(shù)組變量長度為4字節(jié)，根據(jù)E2E配置，前兩個字節(jié)為需要傳遞的應(yīng)用數(shù)據(jù)，比如重要信號扭矩和轉(zhuǎn)速，第三個字節(jié)為發(fā)送計數(shù)器，最后一個為CRC校驗值。測試變量Tlib_En_E2E激活可以在RTE接口數(shù)據(jù)傳輸過程中篡改第二個字節(jié)數(shù)據(jù)。見圖17，故障注入后E2E庫成功識別到故障狀態(tài)為E2E_P01STATUS_WRONGCRC，軟件可以根據(jù)不同的返回狀態(tài)制定不同的后處理策略，以保證系統(tǒng)安全。

圖17 E2E故障注入后數(shù)據(jù)

4 結(jié)論

基于Vector MICROSAR軟件架構(gòu)，設(shè)計了符合車輛功能安全免于干擾需求的混合ASIL系統(tǒng)軟件，并在英飛凌TriCore277控制板上驗證了MPU、PFS和E2E等功能，表明了該應(yīng)用研究對于車輛的安全保護具有重要的意義。同時在獲得上海市科研計劃項目(19XD1432000 SH32E1N三合一電橋總成研發(fā)項目)資助下，成功地將本文的研究成果應(yīng)用到了功能安全量產(chǎn)產(chǎn)品中。