謝凌云

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

0 引言

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

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

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

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

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

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

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

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

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

2.1 內(nèi)存保護(hù)

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

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

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

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

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

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

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

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

2.2 時(shí)序保護(hù)

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

* 執(zhí)行阻塞；

* 死鎖；

* 活鎖；

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

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

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

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

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

(1) Alive Supervision

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

(2) Deadline Supervision

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

(3) Program Flow

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

2.3 通信保護(hù)

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

(1)故障來(lái)源

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

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

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

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

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

* RTE通信故障；

* COM模塊引起的故障；

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

* IOC或OS引起的故障。

(2)錯(cuò)誤類型

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

* 信息重復(fù)；

* 信息丟失；

* 信息延遲;

* 信息插入；

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

* 信息次序不正確

* 信息損壞；

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

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

* 通信信道阻塞。

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

(3)E2E通信保護(hù)機(jī)制

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

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

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

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

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

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

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

圖4 接受方端到端保護(hù)

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

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

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

3 測(cè)試和驗(yàn)證

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

3.1 MPU內(nèi)存保護(hù)

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

圖5 MPU測(cè)試示例

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

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

3.2 PFS時(shí)序保護(hù)

(1)Alive Supervision

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

圖7 Alive Supervision測(cè)試示例

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

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

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

(2)Deadline Supervision

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

圖10 Deadline Supervision測(cè)試示例

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

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

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

(3)Program Flow

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

圖13 Program Flow測(cè)試示例

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

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

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

3.3 E2E通信保護(hù)

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

圖16 E2E測(cè)試示例

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

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

4 結(jié)論

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