AUTOSAR Adaptive平臺 功能安全的分析角度與方法
目的
功能安全是一種系統特性,從AUTOSAR Adaptive平臺開發之初就被考慮在內,因為它可能會影響系統和軟件架構設計決策。因此,AUTOSAR 自適應平臺規范包括與功能安全相關的要求。系統設計的復雜性等方面對于實現汽車行業的功能安全至關重要。
軟件是影響系統級別復雜性的一個參數。可使用軟件開發的新技術和新概念,最大限度地降低復雜性并簡化功能安全的實現。AUTOSAR自適應平臺通過提供安全措施和機制來支持安全相關系統的開發。
但是,AUTOSAR 自適應平臺并不是一個完整的安全解決方案。此安全概述的目標是從頂級安全目標和假定的用例或方案中派生安全需求,并將其分配給項目的架構元素或任何外部度 量。使用 AUTOSAR 自適應平臺并不意味著符合 ISO 26262-10 標準。使用AUTOSAR自適應平臺安全措施和機制構建不安全的系統仍然是可能的。在最好的情況下,AUTOSAR自適應平臺的架構只能被認為是 SEooC。
有關 AUTOSAR 自適應平臺功能安全機制和措施的信息目前分布在引用的文檔中。除非人們知道如何支持功能安全機制以及特定位置的必要信息,否則很難評估如何使用 AUTOSAR有效地實施與安全相關的系統。本解釋性文件總結了AUTOSAR中與功能安全相關的要點,并解釋了如何使用功能安全機制和措施。
范圍
本文檔應具有解釋性,并幫助功能安全工程師在 AUTOSAR 自適應平臺中識別與功能安全相關的主題。本文檔的內容分為以下幾章:
AUTOSAR 自適應平臺目標、用例和場景
系統定義、系統上下文和假設
危害分析
安全目標
功能安全概念映射到ISO 26262中的以下章節,圖1.1:
[3-5] 項目定義
[3-6] 危害分析和風險評估
[3-7] 功能安全概念
如圖 1.2 所示。根據 ISO 21434,安全需求按層次結構進行分層結構,并從危險到安全目標到功能需求和工件進行分配或引用。開發過程和組織主題不是本概述的一部分,沒有進行風險 評估(參見已知限制一章),本文檔中的每個系統描述,場景或用例都只是解釋性的,僅供參考。系統設計不在本文討論范圍!

圖 1.1:ISO 26262 的考慮章節,ISO 26262 系列標準概述,圖 1 - ISO 26262-1 [1]

圖 1.2:安全需求的結構以及本文檔的映射,基于ISO 26262 [1]
目標受眾
本文檔應概述AUTOSAR自適應平臺的功能安全措施和機制,以及它們對參與安全相關(ECU)系統開發的人員的實施。因此,本文檔適用于 AUTOSAR 自適應平臺的用戶,包括參與安全分析的人員。AUTOSAR 特定詞匯表和功能安全相關詞匯表術語由 AUTOSAR 詞匯表 [3] 或 ISO 26262 [1] 本身涵蓋,如果不需要與本文檔相關的其他信息或解釋提示,則不會復制這些術語。
AUTOSAR自適應平臺的使用假設和目標
使用假設
AUTOSAR自適應平臺的使用假設特別包括但不限于來自以下領域的汽車級電子控制單元:
自動駕駛:從駕駛員輔助到全自動駕駛,包括 AD,ADAS和/或Sensor-ECU的生態系統(如適用)
網關
車身域控制器
信息娛樂系統等
為了滿足對更高處理能力的要求,例如傳感器數據處理(圖像,雷達),多傳感器數據融合或機器學習以及增強的多媒體功能,如2D / 3D圖形加速,視頻和音頻處理,AUTOSAR自適應平臺應支持高性能計算單元和加速器,通常通過專用和專有的硬件組件和軟件接口實現。
設計目標
AUTOSAR自適應平臺的整體設計目標與眾所周知且已建立的AUTOSAR經典平臺相似,因此描述了電子控制單元的汽車軟件的抽象層,接口和一些常見行為。AUTOSAR Adaptive Platform仍然為軟件開發人員提供抽象層,例如AUTOSAR Runtime for Adaptive Applications(ARA),因此AUTOSAR Adaptive Platform應用可以在ECU之間交換或輕松移植。從系統的角度來看,這類似于 AUTOSAR 經典平臺 BSW 和 VFB 層 - 如 AUTOSAR 經典平臺架構文檔 [4] [5] 中所述。
第二個主要目標是允許動態軟件升級,并在現場車輛內更靈活地開發和部署應用和服務。
第三個目標,也是功能安全工程師最重要的目標,是能夠在一個分區內執行從QM到ASIL D的混合關鍵性的應用,同時保持免干擾性。如果系統包含多個分區,甚至可能根本不符合ISO 26262標準(或最大QM),就像信息娛樂系統一樣,仍然需要免干擾性,但不在AUTOSAR自適應平臺架構和標準的范圍內。
有關 AUTOSAR 目標(尤其是 AUTOSAR 自適應平臺)的更多詳細信息,請查看 AUTOSAR 簡介演示文稿 [6] 和解釋性 AUTOSAR 自適應平臺設計文檔 [7]。
場景
示例場景:HAD
選擇高度自動駕駛(HAD)場景來研究AUTOSAR自適應平臺的安全功能。此方案不僅滿足了高性能計算和動態軟件更新的要求,還涵蓋了相應的最高安全用 例:符合 ISO 26262 [1] 的 ASIL D。假設車輛級別的系統設計包含多個傳感器,直接連接到傳感器或傳感器 - ECU(例如雷達,激光雷達,視覺,INS,GNSS)。預計該車輛將至少有一個ADAS-ECU用于自動駕駛功能,其中AUTOSAR自適應平臺可以集 成,不僅在ADAS-ECU上,而且在Sensor-ECU或任何其他前面提到的域控制器上。
示例場景:儀表盤
不像HAD那樣安全關鍵,但可以使用ASIL評級的例子是儀表板。雖然儀表板不像HAD那樣對安全需求至關重要,但它也不像信息娛樂系統那樣微不足道。
讓我們考慮一個用例,其中車速表的速度錯誤,駕駛員駕駛速度遠高于限速,從而可能出現個人和其他交通參與者的風險。當故障指示未打開時,可能會發生另一種關鍵情況,例如制動失效,安全氣囊失效或發動機失效。
隨著汽車行業技術的進步,儀表板將需要高性能。在 AUTOSAR 自適應平臺上集成儀表板自然是有意義的,可以滿足高性能要求。反過來, AUTOSAR自適應平臺應確保功能安全需求。
頂級功能需求或用例
根據最初的利益相關者分析和 AUTOSAR 聯盟伙伴要求,已根據 AUTOSAR 自適應平臺的預期用途和范圍確定了以下功能需求:
[SUC-01] 為多個混合關鍵性應用提供靈活的執行時間和資源。
[SUC-02] 為多個混合關鍵性應用提供動態可配置、可更新和可升級的運行時。
[SUC-03]在多個混合關鍵性應用之間提供信息交換。
[SUC-04] 在混合關鍵性應用與車輛內部的傳感器、執行器或ECU等其他外部組件之間提供信息交換。
[SUC-05]在混合關鍵性應用和車輛外部的其他外部組件之間提供信息交換。
[SUC-06] 在駕駛周期內保持正確的配置并監控正確的運行
系統描述
研究元素
本解釋性文檔中正在研究的元素是在第 3 章中大致描述的系統上下文中運行的 AUTOSAR 自適應平臺架構。AUTOSAR Adaptive Platform架構最終將成為軟件組件的基礎,根據ISO 26262-1和ISO 26262-10,它可以被視為一個元素和SEooC。
AUTOSAR自適應平臺旨在獨立于解決方案,除了它是為汽 車工業和根據第2章中描述的目標開發的。盡管如此,它將要執行的平臺也需要進行調查,以便得出一些危險和安全需求。其中一些最終將由AUTOSAR自適應 平臺架構中描述和定義的軟件功能滿足,另一些將分別由OEM或其供應商滿足。現代ECU包含高度模塊化的嵌入式軟件,可以由非安全相關和安全相關軟件組件 組成,這些組件以不同的ASIL等級執行功能。根據ISO26262,如果嵌入式軟件由具有不同ASIL等級的軟件組件組成,則必須根據最高ASIL等級 開發整個軟件,或者對于具有較高ASIL等級的軟件組件,應確保具有較高ASIL等級的軟件組件與具有較低或相同ASIL等級的元件的獨立性,即使或尤其 是如果從較高ASIL的功能分解得到例如 2×ASIL B(D)。
假定的系統上下文
以下系統上下文描述只是有根據的猜測和假設,是推導和解釋安全需求所必需的。
車輛上下文
在最初定義AUTOSAR自適應基準高性能處理單元時,作為SEooC開發的高性能處理單元本身并不總是達到ASIL D的安全等級,因此已經認為一些簡單的系統設計能夠通過適當的分解達到ASIL B或ASIL D。AUTOSAR自適應平臺架構只能支持實際的系統或硬件開發人員實現特定的安全目標。

圖3.1:示范性簡化車輛系統

圖3.3:使用安全檢查器分解
車輛系統設計不是 AUTOSAR自適應平臺規范的一部分,仍然任何一個選項(3.2 和 3.3)都可以是有效的系統設置。最終產品開發人員和安全工程師應選擇適當的系統設計和分解策略,以實現特定的安全目標并滿足特定的安全需求。
電子控制單元上下文
在典型的符合安全標準的 ECU 中,可以假設除了微處理器(uP 或SoC)動態和永久存儲器外,它還將配備電源管理集成電路(PMIC),看門狗和一些板載傳感器或驅動器以及多個輸入輸出通道,例如數字、模擬或通過以 太網等車輛總線進行通信, CAN或 FlexRay。

圖3.4:簡單ECU設計的示例性草案
一些簡單的板上安全措施是:
穩壓和受控電源管理
電源監控(電壓和電流)
溫度監控
活監測(看門狗)
輸入/輸出控制
如果控制器或正在運行的軟件不再可信,例如如果電壓電平不穩定或看門狗已觸發,則 line 驅動程序和收發器可能被禁用,從而在沒有軟件交互的情況下實現故障靜默行為。
微處理器上下文
微處理器或 SoC 設計可能如圖 3.5 所示。

圖 3.5:簡單 MCU 設計的示例性草案
適用于 AUTOSAR 自適應平臺的典型微處理器可能包含多個性能處理內核(uP)、一個硬件安全模塊(HSM),在某些情況下還包含一個外設微控制器內核(uC)。HSM 和 uC 可以是典型的通用控制器,并且是用戶可編程的,或者配備了供應商提供的固件。AUTOSAR 自適應平臺的主要目標是性能處理器。外圍設備可以通過uP訪問,也可能不可以通過uP訪問,外圍設備訪問在AUTOSAR自適應平臺中與AUTOSAR經 典平臺中的級別相同。AUTOSAR自適應平臺的唯一硬件要求是通過運行系統間接定義的,運行系統應提供多進程支持或隔離應用,因此需要根據[8][9] 的內存管理單元(MMU)。如果 ECU 應與其他 ECU 通信,則通過 SOME/IP 協議支持以太網。外部flash和RAM不是直接需要的,而是實際硬件設計中的常見做法(截至2018年)。
硬件加速器
AUTOSAR 自適應平臺架構中遵循硬件加速器和并行處理。有關此主題的詳細信息,請閱讀“在自適應平臺上使用并行處理技術的設計指南 [10]”。硬件加速器的軟件開發過程和所需的軟件機制與典型的微處理器基本相同。應有機制來檢查軟件例程是否正確調度,計算是否正確,控制流是否可監控。
軟件上下文
動態內存分配
自適應平臺供應商和自適應應用開發人員可以在安全相關代碼(包括 ASIL D)中使用動態內存分配,前提是他們確保在分配失效時正確處理和清理錯誤,并且在運行安全相關代碼時,內存分配和解除分配功能(例如 malloc 和 free, new 和 delete)具有確定性性能,這意味著它們的最差執行/阻塞時間是已知值,或者應用專用的安全機制(如看門狗)來處理時序違規。
一般硬件和軟件故障注意事項
硬件不是AUTOSAR自適應平臺架構的一部分,仍然有必要著重硬件來定義最終安全需求的來源。本節將被視為一般的先驗知識,并收集和描述典型的硬件和軟 件故障以及可能直接影響自適應平臺的安全措施。最有可能的是所有硬件和軟件故障都將在這里描述,但并非所有影響都得到充分的分析。因此,必須根據相關行業 標準,對基于 AUTOSAR 自適應 Platform 構建的每個安全關鍵型應用執行全面的安全評估。
潛伏的硬件故障和安全措施
具有混合關鍵性的多個應用的錯誤執行可能是由于系統故障(例如處理器設計中的錯誤)或隨機硬件故障。自然現象,如電離輻射(例如高能粒子撞擊)、電磁順應 性、振動、老化效應或外部環境條件,都可能導致此類故障。在單個平臺上集成具有不同關鍵特性的應用可能非常棘手。可應用硬件級別的分區機制來隔離這些應用 [11]。基于 AUTOSAR 自適應平臺應用的安全關鍵性的硬件分區可確保與軟件或邏輯分區相比,單點故障的影響更小,因為一個硬件分區中的錯誤對其他分區沒有影響。但是,當不同硬件 分區上的兩個應用需要通信時,硬件分區技術可能會有損性能。
我們可將硬件故障分為三個不同的類別:瞬時性、間歇性和永久 性。瞬態故障可能發生一次,并且不可重現(例如,單粒子擾動)。另一方面,間歇性故障時不時發生,但通常以不規則的時間間隔發生(例如,由于溫度或濕度等 環境條件而發生的故障)。顧名思義,永久性故障每次都是可重現的,除非未更換故障組件(例如,單粒子鎖定),否則將持續存在。
以下是為了檢測/避免上述硬件故障可以采取的典型措施列表:
周期配置測試
周期硬件部件測試(使用已知的硬件陣列)
關機路徑測試(“能否達到安全狀態?
內存漫游測試(例如,可寫性測試)
時鐘監控、電源監控、時序監控(由于此類系統固有的復雜性,高性能微處理器中的時序預測可能非常不準確)
合理性檢查(但僅適用于檢查比要監視的功能更容易計算的情況)
外部看門狗
端到端保護
硬件鎖步 CPU 內核(盡管在高性能微處理器中可能并不總是存在這種情況)
ECC 存儲器(數據和地址鏈接的錯誤檢測)
冗余執行 (2oo2, 2oo2D, 2oo3)
正確的硬件設計(由于硬件架構的復雜性,高性能微處理器的選擇可能非常有限,并可能導致共因故障)
正確的通信總線
適當的屏蔽
適當的電磁兼容性(EMC)
潛伏的軟件故障和安全措施
硬件故障可能會直接或間接影響軟件。直接影響的示例可能包括算術誤算(盡管程序的控制流可能是正確的)或錯誤的控制流導致地址跳轉會導致未定義的行為,無 限循環或過早結束執行。間接影響的例子可能包括:影響其他 CPU 內核(運行系統、緩存、內存、外設過載或跨核中斷泛濫或一個內核的強烈發熱導致抖動)、通過軟件導致內存損壞以及運行系統、平臺服務或外設配置錯誤(運行 系統調度表損壞或意外執行“禁用中斷”指令或實時時鐘配置錯誤)。
以下是為了檢測/避免上述軟件故障可采取的一系列典型措施:
冗余執行(2oo2, 2oo2D, 2oo3)
程序流控制(“軟件是否以正確的順序傳遞已知點”)
校驗
仲裁
沖突檢測
簽名
軟件鎖步
并行執行
安全檢查器
強大的安全措施之一是通過AUTOSAR自適應平臺中的軟件檢測和防止故障傳播。故障傳播可以通過執行合理性檢查的軟件監視器來檢測。使用雙模塊化冗余 (DMR),可以檢測到故障。此外,通過三重模塊化冗余(TMR)和投票機制,甚至可以糾正故障。因此,冗余執行有助于檢測是否未更正故障傳播。安全策略 的實施可以幫助檢測訪問沖突,例如用戶進程訪問它沒有訪問權限的資源。
為了避免故障傳播,需對訪問權限進行必要限制。在用戶模式下 應減少權限。如果用戶進程執行特權運行,則運行系統應在授予權限之前運行合理性檢查。但是運行系統和驅動程序可能在特權模式下運行,并成為共因失效的原 因。平臺配置(如 BIOS 設置和特殊寄存器)在運行時應為只讀,在引導運行系統之前應為只讀寫。只應為CPU計算能力、內存和外設以及運行時分配合理的帶寬,以避免因模塊/組件故 障而影響整個系統。防止故障傳播的另一種措施是通過硬件或運行系統對特定資源(如flash、外圍設備等)強制實施互斥。
AUTOSAR 自適應平臺架構概述
AUTOSAR 自適應平臺功能
HAD 場景和生成的 HAD 應用需要以下功能,如下圖 2.2 所示,AUTOSAR 自適應平臺基礎庫和服務(當然,請參考專用 HAD 應用):
安全可靠的啟動
應用的執行
應用調度
應用狀態管理:啟動、停止、停止等
運行時行為監控:處理時間、總線負載、內存消耗等
訪問應用數據
持久數據存儲
配置 ECU 和應用數據
已部署應用的更新
部署新應用
系統監控
通過車輛網絡發送和接收消息:例如 CAN,CAN-FD, FlexRay,以太網
該功能列表不僅與上述 HAD 場景相關,還可以應用于其他特定領域的 ECU,到目前為止,尚未對這些主題進行任何進一步的深入應用和安全分析。
AUTOSAR 自適應平臺架構
AUTOSAR 自適應平臺的分層架構如圖 3.6 所示,可分為圖 2.2 中所述的三個主要部分
AUTOSAR 自適應平臺基礎庫
AUTOSAR 自適應平臺服務
用戶應用(自適應應用和非平臺服務)

圖 3.6:AUTOSAR 自適應平臺功能模塊
運行系統(OS)本身不是架構的直接組成部分,但AUTOSAR Adaptive Platform對運行系統[9]有幾個要求,比如為POSIX PSE51兼容的運行系統[12][13]。
AUTOSAR 自適應平臺功能集群
基礎庫的 AUTOSAR 自適應平臺功能集群 [14] 是:
ara::core Core Types (core) [15]
ara::exec Execution Management (em) [9]
ara::com Communication Management (com) [16] ara::diag Diagnostics (diag) [17]
ara::per Persistency (per)[18]
ara::phm Platform Health Management (phm) [19] ara::iam Identity and Access Management (iam) [20] ara::idsm 入侵檢測系統管理器(idsm)
ara::tsync 時間同步(tsync) [21]
ara::log Log and Trace (log) [22]
ara::crypto Cryptography (crypto) [23]
基礎服務的功能集群是:
ara::sm 狀態管理(sm) [24]
ara::nm 網絡管理(nm) [25]
ara::ucm 更新和配置管理(ucm) [26]
AUTOSAR Adaptive 平臺功能集群的詳細說明可在相應的專業文檔中找到。摘要也是“自適應平臺設計解釋[7]”的一部分。
在 AUTOSAR 中配置 ASIL
本規范旨在支持 ISO 26262 [1] 的汽車安全集成度等級(ASIL)。其他安全完整性級別將不予考慮,也不在本文檔的討論范圍之內。根據ISO 26262-3,ASIL在概念階段被確定為HARA的一部分,并分配給每個安全目標。系統元素、軟件元素或硬件元素將通過系統層次結構將安全需求分配到安全目標,將此 ASIL 作為屬性繼承。
ASIL 存儲為 AdminData,其中包含屬性為 gid=“SAFEX”的 Sdg 數據元素。此元素的內容應包含屬性為 gid=“ASIL”的 Sd 元素。
此屬性的有效值為:
QM
A
B
C
D
QM(A)
QM(B)
QM(C)
QM(D)
A(B)
A(C)
A(D)
B(B)
B(C)
B(D)
C(C)
C(D)
D(D)
請注意,括號表示法用于表示分解的安全需求。在本規范中,我們將原始 ASIL(即括號中的值)稱為分解前的上下文 ASIL,因為它屬于安全目標的上下文。
清單 5.1:元素處 ASIL 屬性的 AUTOSAR XML 表示形式示例
<!-- Example AUTOSAR element with ASIL -->
<APPLICATION-SW-COMPONENT-TYPE>
<SHORT-NAME>MyComponent</SHORT-NAME>
<ADMIN-DATA>
<SDGS>
<SDG GID="SAFEX">
<SD GID="ASIL">B</SD>
</SDGS>
</ADMIN-DATA>
<PORTS>
危害分析
介紹
任何違反安全目標的故障或失效都被認為是危險的。
最常見的安全相關失效或故障是
MCU及其外設的CPU,RAM,Flash或總線中的硬件錯誤
軟件中任何系統性和與安全相關的錯誤(包括等級較低的ASIL或QM錯誤,如果違反免干擾性)
通信線路上的電磁干擾
通信硬件組件中的硬件錯誤
通信驅動程序中的軟件錯誤,導致消息損壞、延遲、丟失、重復、重新排序、插入或偽裝(取自 ISO 26262-6 條款 D2.4)
基于第3.3章中最初的硬件軟件故障考慮因素,上述故障源和安全目標,以及ISO 26262,其中提供了導致軟件組件之間干擾的故障示例,故障可以分為以下幾類:
內存
定時
執行
信息交流
應用和服務的身份驗證
權限管理
頂級失效
AUTOSAR平臺的頂級安全相關失效被認為是
[TLF_01] 意外、不及時和/或不正確地執行應用
[TLF_02] 應用配置、更新和升級的意外、不及時和/或不正確
[TL F_03] 應用之間意外、不及時和/或不正確的信息交換
[TLF_04] 應用與車內外部組件之間意外、不及時和/或不正確的信息交換
[TLF_05]應用與車外外部組件之間意外、不及時和/或不正確的信息交換
[TLF_06] 配置損壞
安全目標
頂級安全需求
AUTOSAR平臺只是“較大”項目定義的一部分,如前幾章所述,架構最終將成為真實軟件組件的基礎,對應于SEooC的元素定義[1]。
[RS_SAF_0 0001] 安全執行:
AUTOSAR應提供支持機制,以監控控制流程并管理具有混合安全關鍵性的多個應用的執行順序。
[RS_SAF_00002]安全配置:
AUTOSAR應提供機制,以便在車輛的整個駕駛周期內提供正確的配置。
[RS_SAF_00003]安全更新或安全升級:
AUTOSAR應提供機制,以支持正確更新和升級具有不同程度的多個平臺和非平臺應用。
[RS_SAF_00004]安全交換信息:
AUTOSAR應提供機制,支持安全關鍵應用之間信息的安全交換(傳輸和接收)。
[RS_SAF_00005]檢測數據損壞:
AUTOSAR應提供機制,以便在處理數據、與其他系統或系統元件通信時檢測故障和故障。
[RS_SAF_00006]安全存儲:
AUTOSAR應提供機制,支持應用的安全存儲。
所有頂級安全需求應達到ASIL D.ASIL D 故障運行 5.1 質量應是可以實現的,即使其中一個頂級安全目標在適用的情況下被違反。
潛伏的產品安全評級或指標

表5.2:用例、失效以及派生的安全需求
(1)AUTOSAR 不對主機應用的安全完整性負責
功能安全概念
派生的 AUTOSAR 平臺功能安全需求
從前面的第4章和第5章中的架構安全目標(5.1)和潛伏危險(4.2)中,并著重一般的硬件和軟件故障考慮因素(3.3),通過走過ECU的典型生命周 期和簡單類別,可得出以下功能需求:安全執行,安全通信,安全存儲以及安全配置和更新。
安全執行
從初始化過程開始:
需要考慮安全初始化 [RS_SAF_10001]
檢查應用和服務的完整性 [RS_SAF_10002]
信息:安全啟動本身根據分層架構,位于AUTOSAR平臺層之下,因此不屬于AUTOSAR平臺架構設計和此安全相關調查的范圍。警惕的安全工程師仍應意識到,在啟動相應的分區之前,需要驗證完整性。
根據最終產品及其環境的架構決策,上述任務的安全影響很難評 估。考慮到 AUTOSAR 自適應應用的動態部署可能性,可能需要在初始化期間執行這些安全功能,以便在支持同一分區上部署的混合關鍵性應用動態配置的環境中保持安全。如果只允許以 安全的方式將預先驗證的配置上載到系統,則在啟動期間只需要進行完整性檢查,以確保應用未被更改。
如果已通過所有這些啟動檢查,則需要提供以下運行時功能:
安全的資源管理,實現免干擾性 [RS_SAF_10008]
應用和服務的可靠調度 [RS_SAF_10028]
安全程序執行 [RS_SAF_10030]
定義的程序執行時間 [RS_SAF_10031]
應用和服務分離 [RS_SAF_10008]
保護應用和服務 [RS_SAF_10008]
安全關閉應用和服務 [RS_SAF_10005]
應用/服務生命周期中狀態的安全轉換 [RS_SAF_10006]
信息:如果底層硬件具有與軟件相同的ASIL等級,則似乎需要進行安全計算,并且僅當硬件的ASIL級別低于功能的要求時才需要進行調查。可組合幾種 AUTOSAR 自適應平臺機制來實現這些目標,例如,重復或冗余執行與某種自檢庫和控制流監控相結合。AUTOSAR Adaptive Platform 可能直接支持具有特定接口或描述的此功能,但如果從一開始就知道這一點,則特定客戶的實現可以簡單的方式遵守此行為,在某些情況下甚至可能對應用透明。
安全通信
在運行時,應用和服務需要相互通信,不僅在同一分區上,而且通過不同的分區、不同的控制器、ECU邊界,甚至與板外通信。此外,動態部署需要對通信伙伴進行身份驗證,因此:
?為應用或服務提供接口,以實現安全通信 [RS_SAF_10014]
如果不滿足依賴關系,則該應用可能處于非完全正常運行狀態,基于整體安全策略,整體的ECU最終被視為不完全運行狀態。
安全存儲
應用和服務還需要在非易失性存儲器單元中持久加載和存儲數據,因此:
防止數據意外更改 [RS_SAF_10037]
檢測數據的意外更改 [RS_SAF_10002]
防止數據或存儲訪問延遲 [RS_SAF_10008]
AUTOSAR自適應平臺特此僅為應用和服務提供接口。硬件特定機制是特定平臺實現的一部分,例如,如NVM是具有磨損均衡功能的eMMC NAND Flash、 EEPROM、NAND、NOR-flash或FRAM等。
安全配置和更新
外部測試人員在不與應用本身交互的情況下修改NvM的可能性只是安全配置和更新的一部分。AUTOSAR 自適應平臺的目標是提供一種手段,即應用可以部署在現場,而不僅僅是在車間或生產過程中。為了防止第一現場部署錯誤的應用,需執行以下任務來維護正確的配置:
驗證是否允許在車輛上部署應用
驗證是否允許在 ECU 上部署應用
驗證是否允許在專用資源上部署應用
這種驗證的一部分確實是檢查是否滿足本地和全局依賴關系,機器/分區的ASIL評級是否具有正確的分類等。最后,所有確保安全初始化和執行的檢查都需要在 部署之前運行,否則在初始化之后,系統可能最終處于故障模式。因此,建議僅在安全狀態下執行安全關鍵應用的更新:
確保安全相關軟件在不會導致危險情況的狀態下更新/升級 [RS_SAF_10038]
如果應用只是配置項,則影響可能不大,因為應用可能只是未計劃。如果應用是更新,則:
緩解或防止對有效配置的未參與或不正確更改 [RS_SAF_10002]
緩解或防止丟失有效配置 [RS_SAF_10027]
動態部署功能對每個基礎模塊或服務都有很大的影響,有助于滿足上述大致描述的安全需求。每個基礎應用或服務都需要從清單中獲取配置數據的可能性,并在初始 化、激活新應用期間動態解釋此數據,或者供應商需要將計算機更新配置作為從基礎開始受影響的應用和服務的附件。特定客戶的行為的特定實現取決于集成平臺的 設計開放程度,以及供應商是否希望并且能夠在現場跟蹤每輛車的每個配置。
AUTOSAR 自適應平臺的安全工件
根據危害分析、安全目標和功能安全需求,確定 AUTOSAR 自適應平臺的以下工件:
確保具有混合關鍵性的多個應用的正確計算、執行和執行順序
[RS_SAF_00001]
EM
PHM
SM
信息:信息架構元素 EM、SM 和 PHM 具有高度安全相關性;安全執行和安全運行狀態管理是自適應應用安全運行的基礎。EM、PHM、SM 元件相互依賴,并協調其活動,以確保 AUTOSAR 自適應平臺內的功能安全。
AUTOSAR應確保在平臺的整個生命周期內進行正確的配置[RS_SAF_00002]
EM
PHM
UCM
PER
AUTOSAR應確保正確更新和升級具有混合關鍵性的多個平臺和非平臺應用
[RS_SAF_00003]
UCM
PHM
CM[E2E]
PER
SM
AUTOSAR應確保信息的正確交換(傳輸和接收)
[RS_SAF_00004]
CM
PHM
AUTOSAR應在處理數據,與其他系統或系統元素通信時檢測故障和故障
[RS_SAF_00005]
CM[E2E]
PHM
PER
已知限制
本解釋性文檔可能包含假設、示例性項目如參考模型、用例、場景和/或對示例性技術解決方案、設備、流程或軟件的引用。本文檔中包含的任何此類假設或示例性 項目僅用于說明目的。這些假設不是AUTOSAR標準的一部分。無論是它們在此類規范中的存在,還是任何實際實施此類示例性項目的AUTOSAR一致性產 品的后續文檔,都并不意味著涵蓋此類項目或假設的知識產權是根據適用于AUTOSAR標準的相同規則許可的。
章節:
技術安全概念
安全需求驗證、安全分析和示例性用例計劃在以后發布。
沒有ASIL評級
AUTOSAR聯盟,特別是AUTOSAR自適應平臺工作組僅提供架構定義,功能模塊的分解和概念驗證實現,不可能在此范圍內為每個架構項目添加ASIL 評級。只能給讀者一些關于如何在他自己非常特定的上下文中組合架構項目以實現安全架構的提示:考慮底層硬件,產品安全目標和指標以及開發過程。
符合 ISO26262 第 10 部分的 SEooC 標準
如果根據ISO 26262,AUTOSAR自適應平臺架構定義本身可以被視為SEooC,則第10部分仍未解決且尚未驗證。根據ISO 26262第1部分中對相關項,元素或架構的定義,架構(在本例中為軟件架構)是相關項或元素結構的表示形式,元素可以是系統,軟件組件或軟件單元,最終也可能是SEooC。無論哪種方式,將ISO 26262第10部分SEooC定義作為本文檔的指南,以創建可重復使用的內容以及與適當的“安全手冊”的相似之處,都可以被視為一個共同的起點。盡管如此,AUTOSAR Adaptive Platform架構仍將最終成為軟件組件的基礎,根據ISO 26262第10部分,該軟件組件可以被視為一個元素和SEooC。AUTOSAR 自適應平臺架構的目標是啟用和支持高達 ASIL D 的系統。

圖 1:相關項、系統、組件、硬件部件和軟件單元的關系圖3 - ISO 26262-10 [1]
網絡安全
對于自動駕駛的網絡安全,預計將產生比過去更大的影響。不僅需要對通信渠道和通信伙伴進行身份驗證和驗證,還需要確保安全。AUTOSAR 自適應平臺的安全概念和功能可在說明性文檔 [2] 中找到。本解釋性文件僅包含安全主題。相應的項目團隊有責任決定是否通過最先進的網絡安全措施實現其特定的安全目標。一些與安全相關的安全功能可能是:
安全啟動
對車輛網絡內以及車外界的通信伙伴進行身份驗證
安全密鑰交換
安全密鑰存儲
...
加密,解密和簽名等安全特定算法不直接被視為與安全相關,它們仍然需要根據ISO 26262以及網絡安全指南和標準進行開發和集成,例如ISO 21434.
完整性
本文檔可能未涵蓋可以使用 AUTOSAR 自適應平臺的所有可能方案。與安全相關的要求來自一些特定的用例,并得到了AUTOSAR自適應平臺工作組所有成員、貢獻者和審閱者的最佳選擇。
A 縮寫

表A.1:縮略語清單
BGlossary
本文檔中使用的所有技術術語(此處列出的術語除外)都可以在官方 AUTOSAR 詞匯表 [3] 或 ISO 26262 [1] 中找到。

表 B.1:詞匯表

