【摘 要】 CP AUTOSAR作為整個汽車行業(yè)一種標準化的開放式架構(gòu)，隨著汽車行業(yè)的發(fā)展，在車載軟件開發(fā)中運用得越來越廣泛，同時汽車作為人們出行的重要交通工具，汽車的安全性也越來越重要。為了開發(fā)滿足ISO 26262的車載軟件，文章分析ISO 26262對軟件安全的要求，并結(jié)合CP AUTOSAR開發(fā)規(guī)范以及CP AUTOSAR的功能安全機制，對CP AUTOSAR的功能安全機制進行深入研究，同時基于ISO 26262的軟件安全要求提出基于AUTOSAR架構(gòu)進行軟件安全機制的應用方案，對當前車載軟件功能安全的實施具有重大意義。
目前基于CP AUTOSAR架構(gòu)開發(fā)汽車電子軟件是主流的主機廠和汽車電子控制器供應商最常見的一種開發(fā)方式。由于汽車電子控制器開發(fā)難度大，在開發(fā)的過程中必須遵循一定的開發(fā)和測試流程，目前汽車行業(yè)最重要的開發(fā)流程是ASPICE和ISO 26262[7]。ASPICE側(cè)重于開發(fā)功能安全相關(guān)性不大的汽車電子控制器，而ISO 26262作為標準的汽車電子控制器安全開發(fā)標準，對于車載電子控制器的安全開發(fā)流程做了嚴格的定義。ISO 26262從系統(tǒng)設計、軟硬件設計、測試、項目管理等方面提供了嚴格的流程和開發(fā)標準。在ISO 26262中，和軟件開發(fā)密切相關(guān)的主要有3大角度，分別是軟件開發(fā)和測試流程、軟件安全分析以及接口免于干擾的要求，軟件安全機制的實施基于接口免于干擾的要求設計和實現(xiàn)[6]。
針對CP AUTOSAR架構(gòu)下的軟件功能安全的開發(fā)必須要明確ISO 26262 內(nèi)對軟件功能安全的要求，基于ISO 26262的要求，將CP AUTOSAR提供的安全機制應用到汽車電子控制器軟件開發(fā)中[5]。在CP AUTOSAR的軟件安全機制中，主要提供了內(nèi)存保護（Memory Protection）、時間保護（WdgM and OS Timing Protection）、數(shù)據(jù)一致性（E2E算法）等安全機制來實現(xiàn)ISO 26262對接口免于干擾的要求。最終基于AUTOSAR的安全機制得出應用結(jié)論，用于安全機制在項目中的實施[8]。
本文以ISO 26262中對軟件開發(fā)的安全要求為基礎(chǔ)，通過識別和選擇CP AUTOSAR內(nèi)提供的安全機制，并且對安全機制進行應用研究和測試，從而針對CP AUTOSAR下的軟件功能安全開發(fā)提供一套完整的方案。整體設計架構(gòu)如圖1所示。
圖1 整體設計架構(gòu)圖
1 CP AUTOSAR介紹
汽車電子開發(fā)不像其他產(chǎn)品的開發(fā)，有著自己一套嚴格的規(guī)范和流程，在汽車行業(yè)主要是V模型，它定義了汽車電子產(chǎn)品開發(fā)一套從需求到軟硬件設計開發(fā)再到最終測試交付的完整體系。AUTOSAR（Automotive Open System Architecture，汽車開放系統(tǒng)架構(gòu)）是主流汽車OEM、供應商、芯片企業(yè)等制定的一套軟硬件可以分離復用、應用算法與底層驅(qū)動分離、下層的芯片企業(yè)與上層OEM或者ECU供應商基于同樣的規(guī)范，獨立并行開發(fā)的軟件開發(fā)體系。AUTOSAR 標準嚴格遵循了V 模型的軟件開發(fā)流程，在AUTOSAR標準中定義了從軟件需求（通用全面的需求）到架構(gòu)設計的完整體系，根據(jù)AUTOSAR規(guī)范就可以開發(fā)滿足這些規(guī)范的代碼程序。在AUTOSAR架構(gòu)中主要分為3層架構(gòu)，分別是APP（Application Layer，應用 層）、RTE（Running Environment，運行環(huán)境）、BSW（Basic Software，基礎(chǔ)軟件層）。整個AUTOSAR架構(gòu)分層如圖2所示。
圖2 AUTOSAR架構(gòu)分層圖
APP層主要是實現(xiàn)特定ECU功能的邏輯算法，這一層也是CP AUTOSAR架構(gòu)里定義的各個OEM和供應商在實現(xiàn)上存在競爭的一層。一般在APP層會設計出ECU中各個軟件單元模塊的上層應用架構(gòu)，而這部分架構(gòu)并不是一個統(tǒng)一的CP AUTOSAR架構(gòu)，OEM和供應商可以根據(jù)自己的應用層邏輯去設計自己上層應用需要的SWC數(shù)目、各個SWC模塊之間的數(shù)據(jù)流和控制流。在CP AUTOSAR架構(gòu)中，各個APP的調(diào)度、數(shù)據(jù)交互等通過RTE實現(xiàn)。
RTE提供基礎(chǔ)的通信服務，支持SWC之間和SWC到BSW的通信（包括ECU內(nèi)部的程序調(diào)用、ECU外部的總線通信等情況）。RTE同時實現(xiàn)對APP層SWC的函數(shù)調(diào)度。RTE使應用層的軟件架構(gòu)完全脫離于具體的單個ECU和BSW。
BSW層是整個CP AUTOSAR的核心，內(nèi)部按架構(gòu)上的分層主要分為微控制器抽象、復雜驅(qū)動層、ECU抽象層、服務層4大部分。各部分的作用如下。
1）微控制器抽象層（Microcontroller Abstraction Layer）是在BSW的最底層，包含了訪問微控制器的驅(qū)動。微控制器抽象層使上層軟件與微控制器相分離，以便應用的移植。
2）復雜驅(qū)動（Complex Drivers）可以實現(xiàn)應用層通過RTE直接訪問硬件，也可以利用復雜驅(qū)動封裝已有的非分層的軟件，以便向CP AUTOSAR軟件架構(gòu)逐步實施。
3）ECU抽象層（ECU Abstraction Layer）封裝了微控制器層以及外圍設備的驅(qū)動，將微控制器內(nèi)外設的訪問進行統(tǒng)一，使上層軟件應用與ECU硬件相剝離。
4）服務層（Service Layer）位于BSW的最上面，將各種基礎(chǔ)軟件功能以服務的形式封裝起來，供應用層調(diào)用。服務層包括RTOS、通信與網(wǎng)絡管理、內(nèi)存管理、診斷服務、狀態(tài)管理、程序監(jiān)控等服務。
2 ISO 26262對軟件安全的要求
ISO 26262是從電子、電氣及可編程器件功能安全基本標準IEC 61508派生出來的，主要定位在汽車行業(yè)中特定的電氣器件、電子設備、可編程電子器件等專門用于汽車領(lǐng)域的部件，旨在提高汽車電子、電氣產(chǎn)品功能安全的國際標準。在汽車電子軟件功能安全開發(fā)過程中，主要關(guān)注ISO 26262的Part6的要求[4]。針對整個ISO 26262-6對軟件開發(fā)的要求，在圖1中已經(jīng)展示，即軟件開發(fā)測試流程、接口免于干擾以及安全分析。軟件和測試流程的要求需要流程管理進行控制，安全分析主要借助一些專業(yè)工具進行分析，而對于接口免于干擾的設計在ISO 26262中提出了明確的要求，而這些接口免于干擾的設計需要在軟件開發(fā)中提供相關(guān)的安全機制來實現(xiàn)。根據(jù)ISO 26262的接口免于干擾的要求，主要從Timing and Execution、Memory、Exchange of Information這3個方面進行分析[12]。
2.1 Timing and Execution
ISO 26262中對時間和執(zhí)行時序相關(guān)的要求做了明確的定義，主要從圖3 列出的5 個方面進行設計和評估。Timing和Execution的分析主要是防止執(zhí)行的函數(shù)被阻塞的時間過長；防止函數(shù)執(zhí)行超過一定的時間；防止函數(shù)調(diào)度過快；防止執(zhí)行時間分配不正確；元素接口等元素不同步。
圖3 Timing and Execution分析內(nèi)容
2.2 Memory
ISO 26262中對Memory相關(guān)要求做了明確的定義，主要從圖4列出的5個方面進行設計和評估。Memory的分析主要是防止數(shù)據(jù)在內(nèi)存中破壞；保證數(shù)據(jù)訪問的一致性；防止內(nèi)存棧空間的上溢出和下溢出；防止數(shù)據(jù)讀寫內(nèi)存地址越界。
圖4 Memory分析內(nèi)容
2.3 Exchange of Information
ISO 26262中對Exchange of Information相關(guān)的要求做了明確的定義，主要從圖5列出的5個方面進行設計和評估。Exchange of Information的分析主要是防止數(shù)據(jù)錯誤；防止數(shù)據(jù)重復操作；防止數(shù)據(jù)丟失；防止數(shù)據(jù)中插入其他數(shù)據(jù)；防止數(shù)據(jù)偽造或者數(shù)據(jù)地址篡改；防止數(shù)據(jù)操作序列出錯；防止數(shù)據(jù)一發(fā)多收出錯；發(fā)送的數(shù)據(jù)被部分接收；數(shù)據(jù)操作被阻塞。
圖5 Exchange of Information分析內(nèi)容
3 CP AUTOSAR安全機制
CP AUTOSAR中根據(jù)ISO 26262的安全相關(guān)需求（Timing and Execution、Memory、Exchange of Information），提出了對應的安全機制，即通過時間保護（WdgM and OS Timing Protection）、內(nèi)存保護（Memory Protection）、數(shù)據(jù)一致性（E2E算法）等安全機制來實現(xiàn)[12]。
3.1 Timing and Execution的安全機制
針對功能安全對Timing and Execution 的安全機制，AUTOSAR 中主要依靠2 個主要的功能來保證，分別是AURTOSAR的WdgM協(xié)議棧以及OS的Timing Protection。每個被監(jiān)控的函數(shù)稱之為一個SE（Supervisor Entity）。在WdgM整個協(xié)議棧中，主要提供了3種監(jiān)控手段，具體的監(jiān)控作用內(nèi)容如下。
1）Alive Supervisor監(jiān)控：周期函數(shù)在特定的時間內(nèi)調(diào)用不能頻率過快或者過慢。SE的WdgM_Checkpoint Reached每調(diào)用一次，對應的Checkpoint的Alive Counter就會加1，主函數(shù)在定義的監(jiān)控周期內(nèi)會去檢測Alive Counter的數(shù)目。只有Alive Counter在該周期內(nèi)屬于定義的次數(shù)范圍才認為該SE處于正常的模式，如果Alive Counter小于定義的調(diào)度次數(shù)最小值則認為所監(jiān)控的SE 執(zhí)行太慢，相反Alive Counter大于定義的調(diào)度次數(shù)最大值，則認為SE執(zhí)行得太快。
2）Deadline Supervisor監(jiān)控：監(jiān)控2個函數(shù)調(diào)用間隔的時間限制。Deadline Supervision主要用于監(jiān)控非周期運行的SE，主要定義了某個事件發(fā)生后，在特定的時間窗內(nèi)去執(zhí)行相應SE的Checkpoint，一般認為在事件發(fā)生后在定義的最短時間和最長時間內(nèi)去執(zhí)行相應的Checkpoint，認為程序?qū)儆谡５膱?zhí)行，如果在事件發(fā)生后執(zhí)行相關(guān)SE的Checkpoint時間小于最小的時間，或者大于最大的時間去執(zhí)行SE的Checkpoint都認為是錯誤的。
3）Logic Supervisor監(jiān)控：監(jiān)控程序按照設計的調(diào)用邏輯進行調(diào)用。主要用于監(jiān)控程序是否按照正確的邏輯轉(zhuǎn)換條件去執(zhí)行。對于每一個Logical Supervision都有一個調(diào)用關(guān)系圖來表示SE中各個Checkpoint點在控制流上的轉(zhuǎn)換關(guān)系。
整個WdgM功能安全監(jiān)控機制如圖6所示。
圖6 WdgM功能安全監(jiān)控機制
在WdgM中，每一個SE都有一個自己的Local Status來表示自己SE的Alive／Deadline／Logic Supervision的狀態(tài)，同時WdgM還有一個全局的Global Status來表示整個監(jiān)控功能的狀態(tài)[3]。在WdgM初始化完成后，每個SE的各個子功能監(jiān)控的Local Status以及Global Status 的狀態(tài)都是OK 的狀態(tài)。每個SE的Local Status以及Global Status都包含了OK、DEACTIVATED、FAILED、EXPIRED狀態(tài)。在每個SE的功能進行監(jiān)控的時候，會根據(jù)監(jiān)控結(jié)果在MainFunction中設置對應的Local Status。其中Alive Supervision有單獨的狀態(tài)設置，而Deadline和Logic Supervision共用一個Local Status。在使用時，可以根據(jù)每個SE 的3 個監(jiān)控設計的條件在MainFunction中設置對應的狀態(tài)，同時MainFunction根據(jù)定義的所有SE的狀態(tài)輸出對應的Global Status，如果最終的Global Status出現(xiàn)錯誤，User可以認為系統(tǒng)的時間或者函數(shù)的調(diào)度功能已經(jīng)導致程序出現(xiàn)了Error，那么可以去觸發(fā)相應的錯誤處理以及故障反應。
除了WdgM對程序的執(zhí)行以及邏輯進行時序的監(jiān)控之外，在Task執(zhí)行的時候，可以通過OS的Timing Protection功能實現(xiàn)對函數(shù)調(diào)度以及Task被Block的時間監(jiān)控。相比于WdgM的監(jiān)控，OS Timing Protection的函數(shù)監(jiān)控更側(cè)重于非功能安全的任務Task調(diào)度以及被Block時間監(jiān)控。OS Timing Protection功能安全監(jiān)控機制如圖7所示。
圖7 OS Timing Protection功能安全監(jiān)控機制
圖7中綠色的是低優(yōu)先級的Task，紅色的是高優(yōu)先級的Task。在實時搶占的系統(tǒng)中，低優(yōu)先級的Task可以被高優(yōu)先級的Task搶占。OS Timing Protection主要考慮低優(yōu)先級的Task在被高優(yōu)先級的Task搶占的情況下執(zhí)行時間不能超過圖中LOW Deadline定義的時間；保證被中斷或者高優(yōu)先級Task Block 的時間不能太長；保證LOW Inter-Arive Time的時間不能調(diào)度太快。在OS Timing Protection中，當達到上述定義的錯誤時，可以選擇相應的安全反應（Reset操作、結(jié)束函數(shù)調(diào)用等）來保證程序的正常運行。
3.2 Memory Protection安全機制
在AUTOSAR中為了保證數(shù)據(jù)訪問過程中不能相互篡改，減少低功能安全等級或者QM的數(shù)據(jù)影響到功能安全的數(shù)據(jù)，需要增加內(nèi)存隔離和內(nèi)存保護。在AUTOSAR提供了基于Application級別的功能安全內(nèi)存保護機制，通過將不同的軟件組件分配到不同的Application中實現(xiàn)內(nèi)存訪問的隔離和內(nèi)存保護。Memory Protection功能安全監(jiān)控機制如圖8所示。
圖8 Memory Protection功能安全監(jiān)控機制
根據(jù)功能安全的目標，將模塊劃分為QM、ASIL-B、ASIL-D。對于每個等級的模塊組件按照功能安全等級進行劃分。需要在內(nèi)存中定義QM、ASIL-B、ASIL-D的3個等級的RAM和ROM空間，并按照圖8的模塊將模塊內(nèi)的變量和代碼分別映射到QM、ASIL-B、ASIL-D的3個等級的RAM和ROM空間，同時結(jié)合圖8中灰色的圖框[硬件MPU（Memory Protection Unit）功能]實現(xiàn)對內(nèi)存的保護[10]。一旦出現(xiàn)低ASIL等級、QM函數(shù)或變量操作到高功能安全等級的，將會觸發(fā)硬件MPU保護措施，并根據(jù)實際應用進行錯誤處理。基于硬件MPU保護的實現(xiàn)邏輯如圖9所示。
圖9 基于硬件MPU保護的實現(xiàn)邏輯
如圖9所示，內(nèi)存保護機制是基于OS進行管理的，因此在實現(xiàn)內(nèi)存保護機制中必須依賴于OS的運行。在集成OS操作系統(tǒng)中程序運行在初始化階段會根據(jù)需要將內(nèi)存保護的地址設置成默認值，或者將芯片全部內(nèi)存設置為都可以訪問[9]。在OS 使用的嵌入式軟件中會存在多個Application，每個Application含有多個Task，OS在運行的時候可以通過調(diào)度切換Application和Task的執(zhí)行，因此OS執(zhí)行過程中會實時對Application和Task進行判斷。當檢測到正在運行的Application或者Task存在內(nèi)存保護機制后根據(jù)設計中定義好的地址范圍操作MPU硬件的RAM和ROM地址，將該Application或者Task訪問的范圍寫入到MPU的寄存器，一旦程序接下來運行的地址超過了定義的范圍，MPU硬件單元便會觸發(fā)硬件錯誤，軟件集成者便可以捕獲該錯誤，并設計錯誤回調(diào)函數(shù)進行錯誤處理。
3.3 Exchange of Information安全機制
針對功能安全提出的對數(shù)據(jù)傳輸和交互過程中出現(xiàn)的要求，在AUTOSAR中提供了E2E（End to End）相關(guān)的算法來保證數(shù)據(jù)在ECU與ECU之間或者ECU內(nèi)部之間的數(shù)據(jù)傳輸?shù)囊恢滦?/span>[2]，圖10展示了E2E保證數(shù)據(jù)傳輸一致性的原理。
圖10 Exchange of Information功能安全監(jiān)控機制
AUTOSAR E2E Lib 提供了多種數(shù)據(jù)一致性保護的算法，主要包括以下幾個方面[11]。CRC Lib：通過填充CRC算法實現(xiàn)；Sequence Counter incremented：發(fā)送方增加，接收方Check 是否增加；Alive Counter：發(fā)送方增加，接收方Check變化，不Check增加；Data ID：每個IPDU Group表明特定的安全元素，特定的ECU信息，Data ID 也會用于CRC 計算；Timeout Detection：接收方檢測數(shù)據(jù)通信超時。
圖10中3種AUTOSAR提供的數(shù)據(jù)一致性實現(xiàn)的方案采用了E2E Protection Wrap（每一個需要保護的數(shù)據(jù)都會使用一個單獨的E2E接口函數(shù)，同時保護數(shù)據(jù)的傳輸必須基于結(jié)構(gòu)體進行）[1]。其中，路徑①代表在同一個ECU中同一個OS Application對發(fā)送和接收的數(shù)據(jù)進行保護，主要采用E2E中的CRC算法實現(xiàn)。路徑②代表數(shù)據(jù)在同一個ECU不同的OS Application進行數(shù)據(jù)傳遞，同時需要增加額外的機制來解決跨OS Application的數(shù)據(jù)交互，即圖10中的IOC模塊，通過增加IOC模塊來保證不同Application數(shù)據(jù)傳輸?shù)囊恢滦浴Ｒ话阒徊捎肅TC算法實現(xiàn)。路徑③實現(xiàn)了在不用的ECU之間數(shù)據(jù)一致性的保護機制，通常這種保護機制一般需要借助ECU之間的通信總線實現(xiàn)，常見的通信總線包括了CAN、LIN、Ethernet等。
4 結(jié)論
上文針對功能安全要求以及對AUTOSAR提供的安全機制分析，將功能安全的要求和安全機制進行了一一對應。針對軟件功能安全中的時間和時序的保護可以使用AUTOSAR架構(gòu)中的WdgM協(xié)議棧，集成WdgM的Alive監(jiān)控、Deadline監(jiān)控以及Logic監(jiān)控實現(xiàn)對程序的時間監(jiān)控，集成OS的時間保護機制可以實現(xiàn)對Task級別的時間保護，避免調(diào)度時間出錯導致功能安全目標的違背；針對軟件功能安全要求的內(nèi)存保護，可以結(jié)合AUTOSAR架構(gòu)中的OS提供的內(nèi)存保護機制設置Application訪問的內(nèi)存區(qū)間，結(jié)合MPU硬件模塊實現(xiàn)對內(nèi)存的訪問權(quán)限隔離，達到內(nèi)存保護的目的；針對軟件功能安全要求的數(shù)據(jù)交互的保護，主要借助于AUTOSAR提供的E2E算法實現(xiàn)ECU內(nèi)部數(shù)據(jù)交互以及ECU與ECU之間數(shù)據(jù)交互的保護。
本文通過研究ISO 26262 的軟件安全要求，結(jié)合AUTOSAR提供的安全機制，從時間、內(nèi)存和數(shù)據(jù)交互3個方面提出了軟件安全機制的實現(xiàn)方案，對當前車載軟件功能安全的實施具有重大意義。
參考文獻：
[1]陳燦，楊興達，方菱.基于決策表的AUTOSAR操作系統(tǒng)一致性測試研究[J].計算機工程與科學，2023，45（4）：622-629.
[2]宋俊飛，翟成超，范慧，等.基于AUTOSAR跨ECU平臺的E2E保護機制的實現(xiàn)[J].汽車電器，2023（3）：25-28.
[3]李思健，石春，吳剛，等.基于AUTOSAR的控制流檢測模塊的設計與實現(xiàn)[J].儀表技術(shù)，2022（4）：1-6，60.
[4]辛強，朱衛(wèi)兵，胡璟.基于ISO 26262的新能源汽車電子電器部件功能安全開發(fā)簡介[J].汽車零部件，2021（6）：63-65.
[5]李爭鵬.基于ISO 26262的驅(qū)動電機系統(tǒng)功能安全概念設計及測試[J].汽車實用技術(shù)，2022，47（23）：160-164.
[6]彭斐.ISO 26262保證汽車功能安全的新思路[J].汽車與配件，2015（37）：30-33.
[7]劉佳熙，于世濤，郭輝.符合ISO 26262要求的汽車起停系統(tǒng)功能安全開發(fā)[J].上海汽車，2014（4）：59-62.
[8]ISO 26262—2018，Road vehicles——Functional safety[S].
[9]葛紋材，朱元，王恩東，等.基于AUTOSAR標準的軟件內(nèi)存保護機制實現(xiàn)[J].信息通信，2020（11）：5-7.
[10]謝凌云.基于ISO 26262混合ASIL系統(tǒng)設計應用研究[J].傳動技術(shù)，2021，35（4）：32-38.
[11]白志浩，張麗，吳肇蘇，等.基于ISO 26262的EV用動力電池系統(tǒng)功能安全設計[J].電源技術(shù)，2021（5）：626-629.
[12]還宏生.汽車設計中的安全要求及ISO 26262標準[J].汽車零部件，2012（10）：41-43.
[13]方曉穎.基于AUTOSAR標準的E2E保護[J].汽車與駕駛維修（維修版），2020（3）：81-83.
轉(zhuǎn)自智能汽車設計
