1、車載智能計算平臺功能安全白皮書（2020 年）目錄編制概要1（一）編制方法1（二）特別說明1一、研究背景3（一）智能網聯汽車的安全體系不斷完善，其中功能安全是關鍵要素3（二）國內外企業競相發力車載智能計算平臺，其功能安全備受重視3（三）車載智能計算平臺功能安全缺少共識，亟需行業專家聯合研究4二、車載智能計算平臺功能安全概述5（一）功能安全及相關標準5（二）安全生命周期7（三）功能安全管理8三、車載智能計算平臺概念階段功能安全11（一）相關項定義及要素劃分11（二）相關項層面的影響分析12（三）危害分析和風險評估12（四）功能安全概念13四、基于功能安全的車載智能計算平臺開發14（一）系統層面1

2、4（二）硬件層面18（三）軟件層面24五、車載智能計算平臺生產、運行、服務和報廢30（一）軟件升級30（二）安全事件應急響應機制30六、發展建議31（一）明確需求統一認識31（二）推進配套工具研發31（三）完善檢測認證體系31（四）加強專業人才培養32附件：縮略語33編制概要（一）編制方法一是研究學習國內外相關文獻，充分參考借鑒國內外最新產業動態和研究成果。二是調研國內外智能網聯汽車、功能安全相關企業，匯集整理和分析來自實踐應用的相關素材。三是邀請行業專家進行技術研討和咨詢評審。（二）特別說明1） 研究聚焦車載智能計算平臺功能安全汽車產業是我國國民經濟的重要支柱產業，是推動實現制造強國和網絡強

3、國建設的重要支撐和融合載體。在“新四化”背景下，汽車電子電氣架構正在由分布式向集中式持續演進，自動駕駛成為產業競爭的焦點，汽車電子產業鏈和技術鏈面臨重構。在此背景下，支撐實現自動駕駛功能的車載智能計算平臺的重要性更加凸顯。國內外企業都在積極布局，加快推進產品研發和應用示范。功能安全、預期功能安全和信息安全構成了智能網聯特別是自動駕駛系統的安全要素。為凝聚共識、形成合力，加強車載智能計算平臺安全體系的研究，推動智能網聯汽車產業高質量發展，在車載智能計算平臺白皮書（2018 年）車載智能計算基礎平臺參考架構 1.0（2019 年）研究的基礎上，本白皮書聚焦車載智能計算平臺的功能安全。2） 研究內容

4、仍有待進一步豐富完善本白皮書的主要觀點和內容僅代表編制組目前對車載智能計算平臺功能安全的研判和思考，與此同時車載智能計算平臺的功能安全仍在探索推進，歡迎各方專家學者和企業代表提出寶貴意見，共同推動研究的及時更新和糾偏。后續中國軟件評測中心將會繼續推出汽車智能計算平臺白皮書（系列）。一、研究背景（一）智能網聯汽車的安全體系不斷完善，其中功能安全是關鍵要素在汽車產業朝著智能化、網聯化、電動化、共享化的“新四化”趨勢不斷深入發展的同時，汽車電子電氣系統的復雜度與集成度不斷提高，新的功能越來越多地觸及到系統安全工程領域。安全是智能網聯汽車持續健康發展的前提。智能網聯汽車安全體系的內涵和外延也在不斷發生

5、變化，功能安全、預期功能安全和信息安全構成了智能網聯特別是自動駕駛體系的安全要素。功能安全的融入是自動駕駛技術發展的客觀要求。功能安全在自 動駕駛系統的全生命周期中起著指引、規范、控制的作用。明確的功 能安全要求、技術方案和規范的功能安全開發流程可以降低和避免來 自系統性失效和隨機硬件失效的風險。系統在運行過程中出現故障時， 也依賴于功能安全機制確保系統進入安全狀態。（二）國內外企業競相發力車載智能計算平臺，其功能安全備受重視自動駕駛技術不斷發展，車載智能計算平臺是 L3 及以上自動駕駛的必要解決方案，也是汽車新型電子電氣架構的核心。其包含異構處理芯片、模組、接口等硬件以及車控操作系統、應用軟

6、件等軟件， 處理海量多源異構數據，是用于實現全部或部分動態駕駛任務和（或） 執行動態駕駛任務接管功能的軟硬件一體化平臺。國內外企業如英偉達、特斯拉、華為、中興、地平線、百度、恒潤等紛紛推出高性能產品。隨著自動駕駛等級的提升，汽車的環境感知、決策權和控制權逐 步實現由駕駛員為主體向自動駕駛系統為主體的過渡，智能網聯汽車 的安全風險急劇增加。車載智能計算平臺的功能安全重要性日益凸顯。車載智能計算平臺及關鍵零部件的開發和集成驗證強化了對安全相 關系統開發流程的需求。整車企業和零部件供應商重視功能安全的研 究和實施，重新賦能技術人員，組織架構或隨之調整。（三）車載智能計算平臺功能安全缺少共識，亟需行業

7、專家聯合研究車載智能計算平臺的功能安全目前尚未形成行業共識。功能安全在 ADAS（Advanced Driver Assistance System，高級駕駛輔助系統） 領域的實踐已形成一定的共識，并主要由 Tier 1（汽車零部件一級供應商）巨頭企業主導。當前對于整車企業、零部件供應商以及自動駕駛解決方案提供商，功能安全在 L3 及以上自動駕駛領域的具體實踐仍在探索推進，行業共識尚未形成，影響了車載智能計算平臺產品功能安全開發以及上車應用。聯合行業優勢資源共同研究車載智能計算平臺的功能安全，可以為我國車載智能計算平臺的技術創新、標準研制、試驗驗證、應用實踐、產業生態構建等提供指導，促進行業上

8、下游達成共識，加速汽車產業和電子產業的融合，推動車載智能計算平臺的持續健康發展。二、車載智能計算平臺功能安全概述（一）功能安全及相關標準道路車輛功能安全的提出主要是降低汽車電子電氣系統的功能異常表現引起的危害而導致的不合理風險。電子電氣系統的失效包括硬件自身的隨機失效及研發過程中引入的系統性失效（軟件失效屬于系統性失效）。車載智能計算平臺實現自動駕駛功能，需要具備可靠冗余的安全設計，其核心系統須達到功能安全相關標準的要求。1）ISO 26262ISO 26262 Road vehicles Functional safety 為汽車電子電氣系統提供了整個安全生命周期功能安全活動的指導。該標準定

9、義了汽車安全生命周期，同時還提出 ASIL（Automotive Safety Integrity Level，汽車安全完整性等級）概念。ASIL 分為A、B、C、D 四個級別，系統的功能安全風險越大，對應的安全要求越高。ASIL D 為最高安全完整性等級，對功能安全的要求最高。ISO 26262 于 2011 年發布第一版，2018 年發布第二版，目前第三版正在研制過程中。國家標準 GB/T34590-2017道路車輛 功能安全修改采用了 ISO 26262-2011。2）SAE J2980SAE（SAE International，國際自動機工程師學會）發布了 SAE J2980 Cons

10、iderations for ISO 26262 ASIL Hazard Classification（ISO 26262 ASIL 危險分類的注意事項）標準，用于指導ASIL 定級。SAE J2980 標準基于 ISO 26262 的既有定義，在 S（Severity，嚴重度）、E（Exposure，暴露率）、C（Controllability，可控性）三個指標的評估 方面做了更詳細的說明，為整車及零部件企業功能安全開發提供參考。3）UL 4600UL 4600 自動駕駛安全評價標準由UL（Underwriters Laboratories，美國保險商實驗室）與Edge Case Resea

11、rch（自動駕駛研究機構）合作開發，是針對自動駕駛系統的安全評估標準。該標準旨在為自動駕駛設計提供完整的安全評價原則和體系，為機器學習、感知操作環境和自動駕駛所需的硬件和軟件提供安全性及可靠性評估。UL 4600 根據自動駕駛系統的當前狀態和對其操作環境的感知，評估自動駕駛系統在無人為干預的情況下安全地執行預期功能的能力，幫助廠商梳理所有與自動駕駛安全相關的領域，標明所有必需測試的項目，從而建立系統的方法，確保設計團隊不會遺漏某個可合理預見的問題。4）ISO TR48042019 年，由寶馬發起，安波福、奧迪、百度、寶馬、大陸、戴姆勒、克萊斯勒、HERE、英飛凌、英特爾、大眾等 11 家公司共

12、同發布了自動駕駛 安全第一白皮書，闡述了如何在自動駕駛系統上綜合運用功能安全、 預期功能安全和信息安全的方法論。 ISO（International Organization for Standardization，國際標準化組織）基于這份白皮書，將發布全球第一個專門針對自動駕駛的應用安全標準ISO TR4804 Road vehicles - Safety and cybersecurity for automated driving systems - Design, verification and validation（道路車輛自動駕駛系統的功能安全和網絡安全設計、驗證和確認）。5）A

13、-SPICEA-SPICE（Automotive Software Process Improvement and Capacity dEtermination，汽車軟件過程改進及能力評定）是汽車行業用于評價軟件開發團隊的研發能力水平的模型框架。最初由歐洲 20 多家整車企業在 SPICE（ISO 15504）的基礎上共同制定，是專門針對汽車軟件開發的行業標準。多年以來，A-SPICE 在歐洲汽車行業內被廣泛用于研發流程改善及供應商的研發能力評價。A-SPICE 根據度量框架將企業的軟件研發能力劃分為 6 個級別，0 級為最低，5 級為最高。（二）安全生命周期功能安全明確定義了安全生命周期，要

14、求將安全生命周期要求融入到自身的流程體系中，建立安全文化，對企業的功能安全做全面管理，滿足 ISO 26262 中對流程活動的要求。功能安全生命周期包括概念階段、產品研發、生產、運行、服務和報廢等階段。概念階段包括相關項定義、危害分析和風險評估、功能安全概念的確定。系統層面的產品開發基于V 模型，包含技術安全要求、系統架構、系統設計和實施、集成、驗證和安全確認。硬件層面的開發過程也是基于 V 模型，包括硬件需求規范、硬件設計和實現、硬件集成和驗證。軟件層面的開發過程同樣是基于 V 模型，包括軟件需求規范、軟件架構設計、軟件單元設計和實現、軟件單元測試、集成和驗證。生產、運行、服務和報廢階段的計

15、劃以及相關要求規范是在系統層面的產品開發階段開始的，并且與系統層面的產品開發、硬件層面的開發、軟件層面的開發同步進行。此階段確保相關項或要素的生產、運行、服務和報廢的功能安全。車載智能計算平臺開發一般為 SEooC（Safety Element out of Context，獨立于環境的安全要素）方式。這種開發方式不會受限于某個具體的項目，需要基于前期市場調研或以往項目積累，對車載智能計算平臺承接的安全目標、功能安全要求以及汽車電子電氣架構做基礎假設。企業可根據自身的產品和業務特性對 ISO 26262 中不必要的章節進行裁剪，將裁剪后的安全生命周期應用到實際的項目中。圖 1 為車載智能計算平

16、臺功能安全生命周期參考示意圖。圖 1 車載智能計算平臺功能安全生命周期參考示意圖（三）功能安全管理車載智能計算平臺功能安全管理貫穿于整個安全生命周期，并與安全生命周期的每個階段并行，大體可以分為整體安全管理、產品開發階段安全管理以及產品發布后的安全管理。整體安全管理側重于企業或部門層面，聚焦功能安全文化建設、功能安全能力建設等。開發階段安全管理側重于產品開發過程中的組織架構、人員配置、開發活動計劃以及文檔交付計劃等。產品發布后的安全管理主要是關注生產和售后層面，包括生產、運行、服務、報廢。在整體安全管理中，質量管理是功能安全管理的基礎，相關企業或部門須具備質量體系，具有獨立的質量部門實施產品質

17、量審核。功能安全部門和質量管理部門可以合二為一，但是功能安全需要滿足獨立性要求。功能安全的管理要求應該融入到基礎質量管理活動中，根據產品不同的功能安全等級要求選擇不同的安全活動以及安全措施。在企業或部門內部要建立一種正向的功能安全文化，鼓勵能夠提升產品安全性的活動。對于功能安全相關人員必須建立完整的能力培養及評定體系，培養識別優秀的功能安全經理及功能安全工程師。同時應當建立起必要的溝通機制以及異常管理機制。在產品開發過程中，需要配備獨立的安全經理跟蹤安全相關的活動，解決安全相關的問題。對每個開發階段，需要制定詳細的開發計劃、驗證計劃以及認可評審計劃。如果涉及到供應商，需要通過簽署DIA（Dev

18、elopment Interface Agreement，開發接口協議）明確雙方責任和義務。在開發計劃中，必須定義各個階段的交付產物以及責任人、交付時間點等。在交付產物中相關內容要建立關聯關系，做到需求和設計、設計和開發、開發和測試雙向可追溯。安全經理需要跟蹤這些活動以及要求的落地，對因為安全導致的成本問題、交付時間問題需要及時溝通，合理有效地協調資源以更好地平衡功能安全和成本、開發時間之間關系。認可評審產品不同的 ASIL 等級需要滿足不同的獨立性要求，必要時可以引入第三方機構進行獨立功能安全評估。在生產、運行、服務和報廢階段，功能安全管理需要定義明確的生產操作規范、維修流程、報廢回收流程保

19、證最終產品在全生命周期不會影響環境及人身安全。三、車載智能計算平臺概念階段功能安全（一）相關項定義及要素劃分相關項是實現車輛層面或部分功能的系統或者系統組。相關項定義并描述系統或系統組，以及其與環境、其他相關項之間的依賴關系和交互影響，為充分理解相關項提供支持，以便執行后續階段的活動。車輛層面的相關項定義如圖 2 所示，主要包括相關項的功能、系統邊界與接口、環境條件和法律要求等。車載智能計算平臺的相關要素主要包括傳感器接入及管理、AI（Artificial Intelligence，人工智能）計算、通用計算、車控、內部通信、V2X（Vehicle to Everything，車用無線通信技術）

20、、高精度地圖數據存儲等。圖 2 相關項定義（二）相關項層面的影響分析車載智能計算平臺的開發項目分為新開發、修改或復用，若為修改和復用，則需要進行相關項層面的影響分析。影響分析應識別和指出因相關項的修改、相關項使用條件的修改所帶來的影響，可能的修改包括運行場景和運行模式、與環境的接口、安裝特性、環境條件等。高級別自動駕駛相對于輔助駕駛在運行環境感知范圍和駕駛任務上會發生變化，例如：1） 設計運行范圍對感知要求的變化相對于輔助駕駛系統面臨的運行環境條件，高級別自動駕駛系統相對減少對駕駛員的依賴，需要感知的車內外環境范圍更廣，以確保自車行駛過程中的道路安全。在某些場景和系統設計中，需要對自車周圍影響

21、道路安全及自車定位的動態和靜態物體感知。2） 動態駕駛任務和人為因素的變化L3 及以上的自動駕駛系統相對于輔助駕駛系統容許一定程度的駕駛員不在環。在系統發現預期無法處理或者無法保證動態駕駛任務安全執行等緊急情況時，為使車輛控制權被快速接管并避免危害，駕駛員狀態也需要被感知（如監測駕駛員專注度、心率等生理狀態）。（三）危害分析和風險評估通過危害分析和風險評估確定 ASIL 等級和安全目標，以避免不合理的風險。為此，根據相關項中潛在的危害事件，對相關項進行評估。安全目標以及分配給它們的 ASIL 等級是通過對危害事件進行系統性的評估所確定的。ASIL 等級是通過對影響因子嚴重度、暴露率和可控性的預

22、估所確定的，影響因子的確定基于相關項的功能行為， 因而不一定需要知道相關項的設計細節。關鍵步驟具體包括場景分析及危害識別、危害分級、ASIL 等級的確定、安全目標的確定。由于在動態駕駛任務中，L3 及以上自動駕駛相對于輔助駕駛，容許一定程度的駕駛員不在環，將會導致對危害的可控性降低，在進行危害分析與風險評估時，可控性或將變為 C3，可能會引起功能安全等級需求的提升。（四）功能安全概念功能安全概念是從安全目標中導出功能安全要求，并將其分配給相關項的初步架構要素或外部措施。功能安全概念包括安全目標、初步安全架構設計、安全分析、安全要求。安全架構設計方面，L3 自動駕駛系統已經允許駕駛員的手長時間脫

23、離方向盤，無需時刻觀察道路狀況，從系統出現失效到駕駛員反應并接管控制存在一定時間間隔。在這段時間間隔內，系統要確保車輛的安全性，需要做到某一個單元失效的情況下，車輛能夠維持橫縱向控制直到駕駛員接管或安全停車，因此需要冗余的架構設計。一般來說，對于整個自動駕駛系統的冗余設計又可以細分為電源冗余、執行機構冗余、傳感器冗余、計算平臺冗余、用戶交互鏈路冗余等。從安全目標可以導出安全要求，安全要求繼承安全目標的 ASIL 等級。一個安全要求可以分解為兩個或多個子安全要求，分配到獨立冗余的安全架構設計中。獨立性是ASIL 分解的重要要求，即冗余單元之間應避免共因失效和級聯失效。四、基于功能安全的車載智能計

24、算平臺開發（一）系統層面1） 應用環境車載智能計算平臺，作為自動駕駛的主要部件，其應用環境參考如圖 3 所示：圖 3 車載智能計算平臺應用環境參考示意圖車載智能計算平臺的應用環境主要包含用于環境感知（如攝像頭、激光雷達、毫米波雷達、超聲波雷達等）和位置定位（如 GNSS、高精度地圖等）的傳感器，整車底盤域、動力域以及車身域的執行器， 人機交互的HMI（Human Machine Interface，人機界面），以及外部互聯與通信的 T-Box（Telematics Box，遠程車載信息交互系統）和 OBD（On Board Diagnostics，車載自動診斷系統）等。隨著自動駕駛等級的不斷提

25、高，車載智能計算平臺對應用環境中的傳感器、執行器、人機接口和外部互聯通信有更高的功能要求及功能安全要求。2） 功能劃分車載智能計算平臺按照功能可以分為傳感器接入及管理、AI 計算、通用計算、通信、存儲和車控等。不同的功能依賴不同的系統模塊實現。傳感器接入與管理單元提供豐富的軟硬件接口，使能傳感器接入及管理。AI 計算提供深度神經網絡算法加速計算能力。通用計算主要是指面向常規算法的計算能力。車載智能計算平臺內部通信提供車載智能計算平臺內部各個要素之間通信能力。V2X 通信提供車載智能計算平臺連接車輛外部設備能力。存儲功能提供諸如高精度地圖存儲及服務能力。車控提供車控下發能力，對接車輛執行器。車載

26、智能計算平臺功能單元參考 ASIL 等級如表 1 所示。表 1 車載智能計算平臺功能單元參考ASIL 等級1功能單元ASIL 等級傳感器接入與管理BAI 計算B通用計算D計算平臺內部通信DV2XD存儲B車控D1 鑒于各企業的解決方案并不相同，表 1 提供的部分功能單元 ASIL 等級并非通用性參考。3） 安全策略自動駕駛功能目前的系統安全策略大體分為兩種，即 Fail-Safe（失效-安全）以及 Fail-Operational（失效-可操作）。Fail-Safe 要求系統監控關鍵的部件以達到失效后系統關斷的目的。但是對于 L3 及以上的功能，駕駛員處于脫眼、脫手的狀態，系統的關閉并不能保證可

27、靠地完成駕駛權的轉移。例如，高速公路場景中，車輛緊急停止在本車道是一種潛在的風險狀態，很容易發生高速追尾。Fail-Operational 安全策略解決了這一問題，即使在主功能系統失效的情況下，仍然有備份系統可以保證車輛進行降級操作，讓車輛轉移到安全區域。4） 系統設計車載智能計算平臺的安全策略可以是獨立的監控模塊或冗余的系統設計。獨立的監控模塊實時監控功能實現模塊的軟硬件故障，一旦檢測到有安全相關故障，車輛即進入安全狀態，如需要可先進入緊急運行模式（Emergency Operation）。例如，功能降級、當前車道停車、安全地點停車等。冗余的系統設計是指兩個或多個功能模塊互為備份。例如，車載

28、 智能計算平臺可以采用“主處理單元+輔處理單元”雙處理架構，以 確保 L3 及以上自動駕駛車輛的安全。在該架構下，主處理單元對車輛的運動軌跡進行規劃和控制，輔處理單元的作用是監控主處理單元。同時兩個單元不斷地進行交叉檢查，當兩個通道在規劃軌跡和控制策 略存在較大偏差時，系統就會進入降級模式。主處理單元和輔處理單 元可以按照ASIL B 設計開發，仲裁模塊可以按照 ASIL D 設計開發。在系統階段進行設計時，需要考慮不同系統單元的故障以及對應的處理策略，具體包括傳感器接入能力失效，比如丟幀、亂序等；通用計算能力或 AI 計算能力失效，比如代碼跑飛、執行超時等；內部或 V2X 通信能力失效，比如

29、超時等；存儲失效，比如高精度地圖數據損壞等；車控失效，比如非預期發送車控等；電源失效；時鐘失效。5） 技術安全概念技術安全概念是車載智能計算平臺系統設計中安全策略與安全 設計的集合。技術安全概念的內容主要包含基于系統架構的功能安全 分析，基于上級功能安全要求與功能安全分析導出的技術安全要求， 最終集成安全設計的系統架構，以及后續生產過程中需要采取的安全 措施。技術安全要求需要定義具體的安全機制并分配到相應的架構要 素中，以確保在下一級的開發過程中，安全機制可以被進一步細化與 實施。在車載智能計算平臺的開發過程中，技術安全概念可能針對于 某一系統或子系統，因而技術安全要求涉及的架構層級可以不止一

30、層。在車載智能計算平臺的技術安全要求中，若采取多層次的技術安全要 求，其基本原則不變，即技術安全要求要與架構層級相映射并最終被 分配到軟件與硬件中，以保證軟件與硬件的功能安全開發有明確和完 整的輸入。6） 測試驗證車載智能計算平臺在功能安全概念階段開發或假設了上層的安 全目標和功能安全要求，安全要求在之后各個階段被逐漸細化和實現。最終完成硬件層面及軟件層面開發和集成的車載智能計算平臺能否正確實現安全要求，以及是否存在非預期的功能，需要通過系統層面的集成測試進行驗證。系統層面的測試驗證，一方面需要確保安全要求能夠被正確地使能，另一方面還需要確保車載智能計算平臺不會因為安全要求非預期使能而導致系統

31、可用性降低。制定有序的系統層面測試計劃，并進行持續的過程跟蹤管理，是保障車載智能計算平臺測試驗證工作有序可靠進行的必要途徑。開發測試團隊應重點考慮項目整體時間計劃、測試驗證的人員安排與責任分工、測試方法、測試環境、測試工具等方面的內容，綜合評估和確認之后形成測試計劃。基于 SEooC 模式開發的車載智能計算平臺實際應用到目標車型時，系統集成測試和整車集成測試是發現系統性故障不可或缺的安全活動。在系統集成測試和整車集成測試活動中，需重點驗證目標車型的功能安全要求是否得到正確實現，集成真實的傳感器和執行器等其他其它要素之后的系統響應是否滿足安全機制的要求，車載智能計算平臺與目標車型其他要素之間的接

32、口與交互過程是否正確，以及安全要求在外界嚴苛的環境條件和運行工況下能否正常實現。（二）硬件層面作為車載智能計算平臺功能軟件與系統軟件的載體，硬件的失效可能直接導致功能軟件輸出不可信任的結果，從而違背安全目標。由于硬件故障在硬件生命周期中發生時間的隨機性，在通過改善流程降低系統性失效的同時，ISO 26262 功能安全標準在硬件層面重點關注識別安全相關的硬件故障以及采取安全機制診斷相應硬件故障，并對發現的硬件故障進行處理（例如進入安全狀態），從而將硬件隨機失效對安全目標的影響降低到可接受的程度。1） 隨機失效概率量化指標根據硬件故障對安全目標產生影響的不同，硬件故障可分為安全相關故障與非安全相關

33、故障，其中安全相關故障又進一步分為單點故障、殘余故障、多點可探測故障、多點可感知故障、多點潛伏故障與安全故障。其中，單點故障和殘余故障可以直接導致安全目標的違背。多點潛伏故障雖然不會單獨導致安全目標的違背，但可能會在與其它故障同時發生時導致安全目標的違背。因此用于表示單點故障與殘余故障診斷覆蓋率的 SPFM（Single-Point Fault Metric，單點故障度量），多點潛伏故障診斷覆蓋率的 LFM（Latent Fault Metric，潛伏故障度量）與 PMHF（Probabilistic Metric for random Hardware Failures，隨機硬件失效概率度量

34、）2是功能安全用于衡量隨機硬件失效率是否達到可接受程度的重要衡量指標。針對于不同的功能安全等級，ISO 26262針對上述指標給出了表 2 中的參考性量化目標。下列數值是廣泛應用于業界評估安全系統是否滿足相應功能安全等級的重要指標。2 對違背安全目標的每個原因進行評估（EEC）是另一種可選度量，參考 ISO 26262-5。表 2 硬件隨機失效度量參考量化目標硬件度量指標ASIL BASIL CASIL DSPFM90 %97 %99 %LFM60 %80 %90 %PMHF<107 h1<107h1<108 h12） 關鍵器件的選型與集成車載智能計算平臺的硬件主要由 AI

35、單元、計算單元與控制單元組成。根據不同的架構需求，上述單元可由一個或多個芯片組成，芯片的種類可能包含GPU（Graphics Processing Unit，圖形處理器）/FPGA（Field Programmable Gate Array，現場可編程邏輯門陣列）/ASIC（Application Specific Integrated Circuit，專用集成電路）、SoC（System on Chip，系統級芯片）、MCU（Micro Control Unit，微控制單元）等。芯片多采取 SEooC 開發模式。安全相關芯片供應商在提供產品的同時會提供給車載智能計算平臺的系統集成者相應的安全

36、使用手冊。安全使用手冊一般包含芯片供應商對系統功能安全要求的假設， 可支持的最高功能安全等級，集成的安全機制以及實現承諾功能安全等級需要滿足的假設條件。車載智能計算平臺選用的安全相關器件需要滿足分配到該器件的技術安全要求。芯片通常會對內部處理單元、存儲單元、通信總線、接口等元件提供相應的安全機制以滿足安全相關故障的診斷覆蓋率要求。除此之外，由于芯片的正常性能表現受限于一定的條件約束， 保證時鐘、溫度、供電等在可操作范圍內的安全機制也對功能安全的實現極為重要。車載智能計算平臺需要按照各芯片廠商提供的安全手冊搭建安全芯片外圍電路和配置內部參數，確保芯片的安全內外部安全機制正常運行，從而在出現故障時

37、能夠及時進入安全狀態。確保每個芯片正確集成的同時，還需確保集成后的硬件架構滿足所有安全目標的隨機失效概率量化指標要求。3） 硬件架構設計由于現有關鍵器件的功能安全能力的局限性與 ASIL D 系統對單點失效度量的嚴格要求，硬件冗余是實現高功能安全等級安全目標的 常見方式。冗余式硬件架構的主體是通過對冗余計算單元輸出結果的 相互校驗達到提高計算單元硬件故障診斷覆蓋率的目的。由于對相互 冗余系統的獨立性要求，相互冗余的系統需盡可能的避免由同源輸入、共用資源、環境影響等因素引起的共因失效。功能安全在硬件層面，關注硬件器件中的安全相關故障可以通過 自檢或外部監控的方式被檢測到，并在故障容忍時間內實現安

38、全狀態。硬件器件實現安全狀態的方式多為重啟、斷電、報錯、禁言等，因此 單硬件通路的硬件架構可以滿足 Fail-Safe 概念的需求。根據車載智能計算硬件平臺所承載功能與功能安全要求分配的不同，AI 單元、計算單元與控制單元所選用的芯片可通過單器件或冗余的方式實現 相應的功能安全等級，如圖 4 所示。圖 4 單硬件通路 Fail-Safe 抽象硬件架構示例隨著自動駕駛的發展，Fail-Safe 的安全策略難以滿足高級別自動駕駛的安全要求。基于 L3 以上自動駕駛功能對系統 Fail-Operational 的需求，越來越多的車載智能計算平臺在主通路實現 ASIL C-ASIL D 的基礎上增加與

39、主通路相互監控的 Fail-Operational 通路，實現主通路失效情況下硬件層面的失效可操作性，以提高系統的安全性和可用性， 如圖 5 所示。需要注意的是，根據自動駕駛功能等級對 Fail-Operational 系統在主通路失效情況下需要完成的緊急運行模式的不同，Fail-Operational 通路所包含的硬件單元可能會有所差異。圖 5 多硬件通路 Fail-Operational 抽象硬件架構示例4） 供電系統設計電源是整車電子電氣架構中最基礎的共用資源。如若電源系統發生失效，則可能導致車載智能計算平臺的所有功能失效，對于 L3 及以上自動駕駛系統是不可接受的風險。車載智能計算平臺

40、的供電系統需要滿足 Fail-Operational 的要求，通常會采用雙電源供電的方式。需要考慮雙路電源供電有足夠的隔離措施，確保一路供電出現故障（電壓過高、過低甚至出現短路）時，另外一路供電不受影響。為滿足車載智能計算平臺系統ASIL D 的要求，參考 ISO 26262- 5 附錄E 中關于電源系統失效模式與應對措施的要求，車載智能計算平臺的供電系統需要能夠監控電源輸入和輸出是否存在異常，尤其是電源系統輸出的監測和控制。若電源系統出現輸出電壓過高或過低故障時，車載智能計算平臺內部的主芯片有可能會因為供電電壓不穩而導致運算結果異常，最終導致違反安全目標。因此，電源系統需在輸出電壓異常時，及

41、時關斷對應的主芯片供電，確保車載智能計算平臺輸出為確定狀態。5） 通信系統設計車載智能計算平臺作為 L3 及以上自動駕駛的運算核心，通常通過專用的通信通道傳輸外界環境信息，而車載智能計算平臺實現融合決策和車輛控制之后，將車輛運動控制指令通過通信總線發送至車輛的縱向和橫向控制執行器。總線通信通道可能因為線束破損、外界電磁干擾和其他節點損壞等因素導致通信失效，包括報文丟失、報文延遲和報文篡改等多種類型的失效模式。參考 ISO 26262-5 附錄D 的要求，采用多種安全監測工具的組合可以滿足高診斷覆蓋率的要求，但此種方法只能滿足 Fail-Safe 的要求，即發現通信故障，但無法維持系統正常工作。

42、為了實現 L3 自動駕駛功能 Fail-Operation 的要求，可采用硬件冗余的方式，一方面提高了診斷覆蓋率，另一方面可滿足 Fail- Operation 的要求。通信通道的冗余設計需要考慮二者的獨立性，例如采用不同類型的通信協議（如 CAN-FD 和 FlexRay），避免發生共因失效。6） 硬件測試車載智能計算平臺的硬件集成完成后，需要對硬件的安全性做全面的測試。硬件測試用例的導出方法包含硬件安全要求分析、內部及外部接口分析、等價類生成和分析、邊界值分析等。硬件測試需要涵蓋功能測試、故障注入測試、電氣測試等測試方法來驗證硬件安全要求的正確性和完整性，另外還需要涵蓋最惡劣情況測試、超限

43、測試、EMC（Electromagnetic Compatibility，電磁兼容）測試和 ESD（Electro- Static Discharge，靜電放電）測試等測試方法來驗證車載智能計算平臺硬件的魯棒性和耐久性。測試完成后需要輸出全面的測試報告作為硬件安全的佐證。（三）軟件層面車載智能計算平臺作為智能汽車的安全關鍵系統，軟件層面的安全性至關重要。由于車載智能計算平臺功能豐富，應用場景復雜，對軟件的實時性、安全性、可靠性要求極高，應通過技術和流程兩個方面保障軟件的功能安全。技術上確保軟件層級的每個功能安全相關軟件節點都有相應的故障監測和處理機制，流程上按照軟件安全生命周期模型規范軟件開發

44、過程。1） 軟件安全要求車載智能計算平臺軟件安全要求是對軟件安全相關的功能和性能的具體要求，主要是通過技術安全要求在軟件層面的分配得到，并通過繼承或分配得到相應的 ASIL 等級。另外，在軟件架構階段執行的軟件安全分析也可能會識別出額外的軟件安全要求。采用專業的需求管理工具來實現需求的編寫、評審、管理以及雙向追溯性檢查可大幅降低軟件層面的系統性安全風險。2） 軟件架構設計軟件架構設計是對軟件需求的設計與實現，用來描述軟件的框架要素和軟件各分層結構之間的相互作用，其范圍層面應到能夠識別所有軟件單元的程度。軟件架構設計不僅需滿足相應 ASIL 等級的軟件安全要求，還應滿足軟件其他非安全要求。在軟件

45、架構層面，軟件安全要求會分層次地分配給軟件組件直到軟件單元，每個軟件組件應按照分配給它的安全要求中最高的 ASIL 等級來開發。車載智能計算平臺應在軟件架構設計階段進行軟件安全分析和相關失效分析，完善錯誤探測和錯誤處理的安全機制，以便識別或確認軟件安全相關部分， 證明軟件的安全相關的功能和性能滿足相應的 ASIL 要求，支持安全措施的定義及其有效性。車載智能計算平臺軟件架構設計完成后，應對其開展驗證活動，輸出軟件驗證報告，證明軟件架構設計嚴格遵守設計規則，兼容目標環境，滿足相應ASIL 等級的需求，并且相關評審證據充足。3） 軟件單元設計與實現在軟件單元設計與實現階段，基于軟件架構設計對車載智

46、能計算平臺的軟件單元進行詳細設計。軟件單元設計應滿足其所分配的ASIL 等級要求，與軟件架構設計和軟硬件接口設計相關內容保持一致。為了避免系統性失效，應確保軟件單元設計的一致性、可理解性、可維護性和可驗證性，應采用自然語言與半形式化方法相結合的方式進行描述。說明書應描述實施細節層面的功能行為和內部設計，包括數據存儲和寄存器的使用限制。在源代碼層面的設計與實施應使得軟件單元設計簡單易懂，軟件修改適宜，具有可驗證性和魯棒性，確保軟件單元中子程序或函數執行的正確次序，軟件單元之間接口的一致性，軟件單元內部及軟件單元之間數據流和控制流的正確性。車載智能計算平臺軟件包含數百個軟件單元，軟件單元的標準化、

47、單元間解耦是高效實現軟件功能安全的基礎。車載智能計算平臺中不同安全等級的軟件可以采用硬件虛擬化、容器、內存隔離等技術進行隔離，防止軟件單元之間的級聯失效。軟件代碼設計過程中應遵守成熟的代碼設計規范，例如 MISRA C（汽車產業軟件可靠性協會嵌入式 C 編碼標準）。企業可以基于 MISRA C 建立一套滿足車載智能計算平臺安全編碼要求的內部編碼規范，并嚴格執行。4） 軟件單元驗證軟件單元驗證是通過評審、分析和測試的方法對功能安全相關的軟件單元設計與實現進行驗證，證明軟件相關安全措施已經在設計與實現中全部落實。軟件單元設計滿足相應的 ASIL 等級的軟件需求和軟硬件接口規范要求，軟件源代碼的實現

48、與單元設計一致，不存在非期望的功能和性能，且支持功能和性能實現的相關資源充足。車載智能計算平臺的軟件單元驗證可通過需求分析、等價類的生成與分析、邊界值分析和錯誤推測相結合的方法合理設計測試用例， 確保對軟件單元進行充分驗證。為了評估軟件單元驗證的完整性，為單元測試的充分性提供證據，應確定在軟件單元層面的需求覆蓋率， 同時對結構覆蓋率進行測定。車載智能計算平臺軟件單元測試的結構覆蓋率目標為 100%，如果已實現結構覆蓋率不能達到目標，可以定義額外的測試用例并提供接受理由。車載智能計算平臺軟件單元的結構覆蓋率測試應采用滿足相關安全要求的測試工具，確保在測試過程中測試工具和檢測代碼不會對測試結果產生

49、影響。車載智能計算平臺軟件單元測試應根據測試范圍，選用適當的測試環境。測試環境應適合完成測試目標，盡可能接近目標環境，如果不是在目標環境執行，應分析源代碼與目標代碼的差異、測試環境和目標環境之間的差異，以便在后續測試階段的目標環境中，定義額外的測試。5） 軟件集成驗證軟件集成驗證需要根據軟件驗證計劃、接口規范、軟件架構設計規范、軟件驗證規范等對軟件架構中所描述的集成層次、接口、功能等進行持續測試，以驗證其與設計的符合性。由于車載智能計算平臺軟件的復雜性，實時性、可靠性、安全性既是設計目標也是基礎性能，集成測試設計階段應對其功能、邏輯、性能、邊界、接口進行詳細分析。車載智能計算平臺的軟件集成驗證

50、，不僅需涵蓋所有應用軟件、功能軟件、系統軟件以及與硬件之間的接口，并且應涵蓋軟件單元之間的接口。測試用例在測試工作中至關重要，其輸出需要考慮功能需求、性能需求、邊界值、接口、邏輯關系等。6） 嵌入式軟件測試車載智能計算平臺嵌入式軟件測試主要是基于軟件安全要求的測試，并針對軟件安全要求進行充分的故障注入測試，最終確保軟件安全要求的正確實現。為了驗證車載智能計算平臺軟件在目標環境下是否滿足軟件安全要求，應進行硬件在環測試、車輛電控系統和網絡通信環境下的測試以及實車測試。硬件在環測試是將車載智能計算平臺軟件燒寫到目標芯片中，在目標芯片的硬件異構平臺環境下驗證軟件的安全要求。然后，將車載智能計算平臺與

51、部分或全部的車輛電子電氣設備進行網絡通信，在車輛電控系統和網絡環境下驗證軟件的安全要求。最后，將車載智能計算平臺安裝到實際車輛中，進行軟件安全要求的驗證與確認。7） 人工智能通過實施完善的開發流程可降低車載智能計算平臺人工智能的系統性安全風險。車載智能計算平臺人工智能的開發包含需求分析、算法設計、數據采集和標注、模型訓練、測試驗證以及運行等流程。人工智能的需求分析應包含算法的基本功能需求和功能安全要求（如算法精度目標、算法 Fail-Operational 等）。算法設計階段應考慮采用多算法、多模型、多幀數據、多傳感器等多種冗余機制的組合以提升 安全性。數據采集和標注階段應確保數據標注精度、數

52、據場景分布， 并避免數據錯標和漏標，從而確保模型訓練不受影響。模型訓練階段 采用業界成熟、文檔全面的人工智能框架。測試驗證階段對所有需求 進行閉環的測試，同時全面考慮各種潛在應用場景及環境影響因素， 進行長距離的實車試驗。根據測試結果不斷重復進行數據的采集、標 注、模型訓練和測試驗證的階段，通過迭代的方式逐步提高人工智能 的安全性。在運行階段，應持續地對實際運行數據和人工智能的安全 性進行監控，通過分析實際運行數據對人工智能算法和模型不斷優化。五、車載智能計算平臺生產、運行、服務和報廢（一）軟件升級在智能網聯汽車中應用 OTA（Over-the-Air，空中升級）已經成為當前市場上一種主流的趨

53、勢。使用 OTA 進行軟件升級能夠快速更新迭代整車功能，或者修復軟件缺陷。車載智能計算平臺搭載的深度學習和視覺模塊和地圖數據等部件甚至基礎固件均可以通過 OTA 及時更新，甚至完全擴展出新的功能，更新內部軟件程序后的車載高性能運算平臺仍需要保證原有的安全性，杜絕因為 OTA 過程中存在系統性失效而引發人身傷害。此外，OTA 過程通常發生在車輛 SOP（Standard Operation Procedure，標準作業程序）之后的運行維護過程中，整車企業和軟件開發工程師難以直觀地控制所有車輛的 OTA 過程，因此保證 OTA 完整流程的安全性是車載智能計算平臺必須考慮的因素。作為整車企業與Tier 1，應當從安裝