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