本文由劉法旺，李艷文，王偉，李京泰聯合創作
車載智能計算基礎平臺是汽車產業發展的重要基礎和支撐重構下一代汽車電子產業鏈的關鍵紐帶，安全問題至關重要。本文首先針對車載智能計算基礎平臺，從安全策略和系統設計兩個層面進行功能安全分析；然后對平臺的異構硬件、操作系統、開發工具鏈，分別研究提出功能安全要求；最后從流程、設計開發、測試驗證三個層面，研究提出車載智能計算基礎平臺功能安全的評估框架。
在智能化、網聯化、電動化的背景下，汽車電子電氣架構由分布式向集中式持續演進，自動駕駛成為產業競爭的焦點。作為實現自動駕駛的關鍵，車載智能計算基礎平臺的重要性更加凸顯。
發展車載智能計算基礎平臺，有利于聚集多領域、跨行業的創新資源，打通基礎研究、應用示范、成果轉化與產業化的鏈條，集中力量在自動駕駛核心競爭領域形成原始創新能力和競爭優勢。特斯拉、奧迪、英偉達、華為等整車企業和科技公司紛紛推出計算基礎平臺。
車載智能計算基礎平臺是基于異構分布式硬件平臺，融合并集成系統軟件、功能軟件的復雜系統，可根據差異化需求進行硬件定制和應用軟件加載，滿足自動駕駛等功能需求。計算基礎平臺硬件架構主要包括 AI 單元、計算單元和控制單元。面向自動駕駛的車控操作系統，包含基于復雜嵌入式系統的汽車定制化系統軟件和密切結合自動化需求的通用功能軟件。其中，功能軟件包括深度學習和視覺模塊、傳感器模塊、網聯云控、自動駕駛通用框架等模塊。
自動駕駛強化了智能網聯汽車基礎計算平臺對功能安全的要求。隨著自動駕駛等級的提升，汽車的環境感知、決策權和操控權逐步實現由駕駛員為主體向自動駕駛系統為主體的過渡，智能網聯汽車的安全風險大幅增加。異構分布硬件系統需要滿足高診斷覆蓋率和低失效率指標要求，自動駕駛車控操作系統需要滿足實時性、安全性、可靠性等要求，工具鏈則需要滿足置信度等要求。
本文基于自動駕駛功能應用背景，對計算基礎平臺參考架構從功能安全分析、要求、評估三個方面展開研究。
智能網聯汽車計算基礎平臺的應用環境主要包含用于環境感知（如攝像頭、激光雷達、毫米波雷達、超聲波雷達等）和位置定位（如 GNSS、高精度地圖等）的傳感器，整車底盤域、動力域以及車身域的執行器，人機交互的 HMI（Human Machine Interface，人機界面），以及外部互聯與通信的 T-Box（Telematics Box，遠程車載信息交互系統）和 OBD（On Board Diagnostics，車載自動診斷系統）等。隨著自動駕駛等級的不斷提高，智能網聯汽車計算基礎平臺對應用環境的傳感器、執行器、人機接口和外部互聯通信有更高的功能要求及功能安全要求。
計算基礎平臺參考架構如圖 1 所示。
圖1 計算基礎平臺參考架構
1.1 安全策略要求
自動駕駛功能目前的系統安全策略大體分為兩種，即 Fail-Safe（失效—安全）以及 Fail-Operational（失效—可操作）。Fail-Safe 要求系統監控關鍵的部件以達到失效后系統關斷的目的。但是對于 L3 及以上的功能，駕駛員處于脫眼、脫手的狀態，系統的關斷并不能保證可靠地完成駕駛權的轉移。例如，高速公路場景中，車輛緊急停止在本車道是一種潛在的風險狀態，很容易發生高速追尾。Fail-Operational 安全策略旨在解決這一問 題，即使在主功能系統失效的情況下，仍然有備份系統可以保證車輛進行降級操作，讓車輛轉移到安全區域。
1.2 系統設計功能安全要求
智能網聯汽車計算基礎平臺的安全策略可以是獨立的監控模塊或冗余的系統設計。獨立的監控模塊實時監控功能實現模塊的軟硬件故障，一旦檢測到有安全相關故障，車輛即進入安全狀態，如需要可先進入緊急運行模式（Emergency Operation）。例如，功能降級、當前車道停車、安全地點停車。
冗余的系統設計是指兩個或多個功能模塊互為備份。例如，計算基礎平臺可以采用“主處理單元 + 輔處理單元”雙處理架構，以確保 L3 級及以上自動駕駛的安全。在該架構下，主處理單元對車輛的運動軌跡進行規劃和控制。輔處理單元的作用是監控主處理單元。同時兩個單元不斷地進行交叉檢查，當兩個通道在規劃軌跡和控制策略存在較大偏差時，系統就會進入降級模式。主處理單元和輔處理單元可以按照 ASIL B 設計開發，仲裁模塊可以按照 ASIL D 開發來設計。
在系統階段進行設計時，需要考慮不同功能單元的故障以及對應的處理策略，具體包括傳感器接入能力失效，比如丟幀、亂序等；通用計算能力或 AI 計算能力失效，比如代碼跑飛、執行超時等；內部通信及 V2X 能力失效，比如超時等；存儲失效，比如高精度地圖數據損壞等；電源失效 ；時鐘失效。?
計算基礎平臺加載自動駕駛應用程序，進而實現自動駕駛功能。對高等級自動駕駛功能進行分析，涉及到轉向和制動的功能安全等級要達到 ASIL D 要求。根據功能安全 ASIL 等級分配和分解原則，計算基礎平臺需要滿足 ASIL D 要求。基于計算基礎平臺的不同實現技術方案，自動駕駛操作系統和異構硬件分布架構需要各自的 ASIL 等要求。
2.1 異構硬件架構功能安全要求
異構架構主要包括 AI 單元、計算單元和控制單元。根據不同的架構需求，這些單元可由一個或多個芯片組成，芯片的種類可能包含 GPU/FPGA/ASIC、SoC、MCU 等。
由于現有關鍵器件的功能安全能力的局限性與 ASIL D 系統對單點失效度量的嚴格要求，硬件冗余是實現高功能安全等級安全目標的常見方式。冗余式硬件架構的主體是通過對冗余計算單元輸出結果的相互校驗達到提高計算單元硬件故障診斷覆蓋率的目的。由于對相互冗余系統的獨立性要求，相互冗余的系統需盡可能的避免由同源輸入、共用資源、環境影響等因素引起的共因失效。
功能安全在硬件層面關注硬件器件中的安全相關故障可以通過自檢或外部監控的方式被檢測到，并在故障容忍時間內實現安全狀態。硬件器件實現安全狀態的方式多為重啟、斷電、報錯、禁言等，因此單硬件通路的硬件架構可以滿足 Fail-Safe 概念的需求。根據車載智能計算硬件平臺所承載功能與功能安全要求分配的不同，AI 單元、計算單元與控制單元所選用的芯片可通過單器件或冗余的方式實現相應的功能安全等級，如圖 2 所示。
圖2 單硬件通路Fail-Safe抽象硬件架構
圖3 多硬件通路Fail-Operational抽象硬件架構
隨著自動駕駛的發展，Fail-Safe 的安全策略難以滿足高等級自動駕駛的安全要求。基于 L3 以上自動駕駛功能對系統 Fail-Operational 的需求，越來越多的車載智能計算平臺在主通路實現 ASIL C-ASIL D 的基礎上增加與主通路相互監控的 Fail-Operational 通路來實現主通路失效情況下硬件層面的失效可操作性，以提高系統的安全性和可用性，如圖 3 所示。?
2.2 車控操作系統軟件功能安全要求
自動駕駛操作系統軟件是計算基礎平臺的核心，包括功能軟件和系統軟件兩部分。功能軟件融合多種跨產業技術，基于自動駕駛共性需求對通用模塊進行定義和實現，主要包括自動駕駛通用框架模塊、傳感器抽象功能、感知融合功能、預測功能、定位功能、決策規劃功能、執行器抽象功能等。系統軟件是提供公共服務和管理、支撐軟件運行的載體，面向底層提供基于異構分布式硬件 / 芯片組合的硬件系統，為上層的軟件系統提供與硬件無關的運行環境和開發接口，主要包括虛擬化軟件、操作系統內核、中間件等組件。
基于不同的自動駕駛應用場景，功能軟件需滿足對應的 ASIL 等級要求。主要通過軟件功能安全技術和流程來保障。技術上，功能軟件需采用容錯技術和避錯技術，在每個軟件層級的每個功能安全相關軟件節點都有相應的故障監測和處理機制；流程上，需按照軟件功能安全、ASPICE 等要求，避免系統性失效。
系統軟件同樣需要滿足軟件功能安全技術和流程要求。由于計算基礎平臺架構中各單元有多重不同安全等級的需求，是典型的混合關鍵性系統，需要多內核功能安全設計。多內核應滿足安全性和實時性要求，提供空間地址保護，保障各操作系統服務通過協作的用戶進程實現，在獨立的地址空間運行。
系統軟件的虛擬化組件需滿足高等級功能安要求。如 Hypervisor 組件可以將關鍵安全系統與非關鍵安全系統分區和隔離，從而確保關鍵系統被隔離并在系統發生故障時進行安全管理。不同 ASIL 等級要求的軟件組件在共享資源時應使用有免于干擾的機制，避免沖突。
圖4 軟件架構組件免干擾機制
如圖 4 所示，一個 QM 軟件要素干擾并阻止了 ASIL 等級軟件要素的及時執行。這樣的干擾也可能發生在不同 ASIL 等級的軟件組件之間。通過在軟件中引入“檢測點”并對檢測點進行超時監控，可探測到時序干擾并觸發合適的響應， 實現有免于干擾的機制。
系統軟件需要借鑒 Adaptive AUTOSAR，采用 POSIX 接口，并滿足功能安全要求。POSIX 能夠滿足自動駕駛所需要的高性能計算和高寬帶通信等需求。系統軟件讓不同的內核支持 POSIX API 以支撐 AUTOSAR 規范中的規定的基礎功能及服務。通過 CRC 校驗、定時器等功能安全措施識別報文丟失、報文延遲和報文篡改等通信接口失效，保障 API 接口的功能安全滿足需求。
2.3 工具鏈能安全要求
功能安全標準提出了對軟件工具的置信度要求。計算基礎平臺工具鏈主要包括開發工具、集成工具、仿真工具、調試工具和測試工具，屬于含軟件的工具類別，為保障自動駕駛功能達到 ASIL D 等級，工具鏈需滿足功能安全工具置信度要求。
軟件工具置信度的相關安全分析工作主要分為三個階段：分級階段，對工具進行分析和評估，是否需要鑒定；鑒定階段，對有需求的關鍵性工具進行鑒定；使用階段，安全地使用這個工具。
圖5 工具鏈置信度分析
在軟件工具置信度分析過程中，主要得到四個文檔，如圖 5 所示。工具分級報告（TCR，Tool Classification Report），工具分級的結果，包含對工具中潛在錯誤的風險分析；工具安全手冊（TSM，Tool Safety Manual），工具使用時應遵守的手冊，包含對用戶使用工具時重要的安全說明，如工具中的潛在錯誤、實際錯誤、其他的已知錯誤（Known Bug），以及用戶需要執行的各項緩解措施等；工具鑒定計劃（TQP，Tool Qualification Plan），描述工具鑒定時，針對工具的某個功能或某個步驟所計劃執行的相關措施（主要是測試）；工具鑒定報告（TQR， Tool Qualification Report），工具鑒定的結果，主要是測試結果。
TSM 中的內容也體現了分級的結果。如果分級時將工具的某些功能歸為“未使用”，則用戶在實際開發時也不允許使用它們。如果在分級的時候指定通過緩解措施可以識別 / 避免一些潛在錯誤，那么這個措施也必須寫在安全手冊中，用戶在使用時也必須如此執行。如果將一些潛在的工具錯誤被分級為無法 / 很難檢測到，那么必須對這個工具進行鑒定，即通過測試的手段，以確保這些潛在的錯誤不再造成麻煩。通過測試，一些潛在錯誤會被排除，一些潛在錯誤會轉化為實際的、具體的工具錯誤。針對這些存在的錯誤，需要采取一些相應的檢測 / 避免措施，這些措施也必須包括在安全手冊中。另外，在 TSM 中還需要包括相關的已知錯誤（Known Bug）的處理對策。
為確認計算基礎計算平臺達到了 ASIL D 的要求， 需要對其進行功能安全評估。本文提出了三維評估框架，從流程、開發過程、測試驗證三個方面展開，綜合確認計算基礎平臺的功能安全合規性。
3.1 流程評估
流程評估主要是對功能安全管理、生產和運行、支持過程等內容進行審核，確認計算基礎平臺在這些階段的活動符合要求，能夠通過合規的流程避免或減少系統性風險，提高開發效率。功能安全管理要符合整體功能安全管理、產品開發過程的安全管理和生產發布后的安全管理預期。計算基礎平臺要符合生產、運行、服務和報廢相關的活動要求。要滿足功能安全支持過程要求，如變更管理、配置管理、文檔管理、分布式開發接口、安全要求的定義和管理、軟件組件鑒定、硬件要素評估等。
3.2 設計開發評估
開發過程評估主要是對系統階段、硬件階段和軟件階段進行審核，確認計算基礎平臺產品在開發過程中符合各階段功能安全技術要求。系統階段功能安全評估主要是確認計算基礎平臺按照功能安全要求進行了系統架構設計及分析，提出技術安全要求，分配給軟硬件接口規范。硬件階段功能安全評估主要是確認計算基礎平臺按照功能安全要求進行了硬件安全要求定義、硬件功能安全指標評估。軟件階段功能安全評估主要是確認計算基礎平臺按照功能安全要求進行了軟件安全要求定義和軟件架構設計。
3.3 測試驗證評估
測試驗證評估主要是對計算基礎平臺軟硬件以及系統集成測試結果進行評估，確認產品開發的安全需求得以實現。
自動駕駛系統完成硬件和軟件開發后，進入集成和測試階段，主要驗證在自動駕駛系統架構層面開展的安全分析所定義的安全措施是否得到了正確實施，為集成后的系統滿足根據自動駕駛系統架構所設計的安全要求提供充足的證明。軟硬件集成測試的對象是自動駕駛系統內 / 外部的軟硬件接口，為軟硬件接口是否符合接口規范定義提供證明。系統集成測試的對象是集成后的自動駕駛系統，為自動駕駛系統的要素正確交互、符合技術要求和功能安全要求提供證明，并為不可能導致違背安全目標的非預期行為提供足夠的置信度水平。整車集成測試的對象是集成了自動駕駛系統的整車，為集成后整車系統故障造成的非預期風險足夠低提供證明。
智能網聯汽車計算基礎平臺基于異構分布的硬件平臺，集成自動駕駛操作系統，提供高性能計算力，實現集中控制策略，保障智能網聯汽車感知、決策、規劃、控制模塊的高速可靠運行。隨著自動駕駛級別的提升，自動駕駛系統所需要處理的數據呈幾何倍增，自動駕駛系統實時性要求、安全等級要求不斷提高。
本文以智能網聯汽車計算基礎平臺為對象進行功能安策略和系統設計分析。對異構分布硬件的單硬件通道和多硬件通道分別提出 Fail-Safe、Fail-Operational 要求；對車控操作系統軟件進行免干擾機制分析；對工具鏈提出置信度分析過程。最后，提出智能網聯汽車計算基礎平臺多維功能安全評估框架，確認平臺產品開發符合功能安全要求。
參考文獻
[1] 李克強.智能網聯汽車系統基礎平臺及其產業化對策[J].智 能網聯汽車,2019(1):40.
[2] 中國軟件評測中心.車載智能計算基礎平臺參考架構1.0[J]. 智能網聯汽車,2019(4):85-94.
[3] 汽車工程學會.中國智能網聯汽車產業發展報告[M].北京: 社會科學文獻出版社,2020.?
[4] Collin A,Siddiqi A,Imanishi Y,et al.Autonomous driving systems hardware and software architecture exploration:optimizing latency and cost under safety constraints[J].Systems Engineering,2020,23:327-37.
[5] Behere S,T?rngren M.A functional reference architecture for autonomous driving[J].Information and Software Technology.2016,73:136-50.
[6] Pimentel J.Fail-Operational Safety Architecture for ADAS Systems Considering Domain ECUs[C]//The Safety of Controllers,Sensors,and Actuators.2018.
[7] 中國軟件評測中心.車載智能計算平臺功能安全白皮書[J]. 智能網聯汽車,2020(4):18-24.
[8] 趙正旭,白英杰,吳曉進.國產操作系統JSP服務器部署策略的設計與實現[J].軟件,2018,39(6):196-200.
[9] 李潔,何軍.云計算操作系統網絡虛擬化模塊Neutron分析研究[J].軟件,2016,37(01):21-23.
[10] 胡楊.Rtems 嵌入式操作系統的移植[J].軟件,2015,36(12): 108-113.
[11] 嚴剛,肖堃,褚文博.智能網聯汽車計算平臺虛擬化技術研究[J].汽車工程,2020,42(1):33-37+58.
[12] 馬文輝,郭云川,張會兵,等.安全多執行機制的無干擾性研 究[J].軟件,2015,36(6):83-87.
[13] 蘇奎,張彥超,董默.一種計算機安全評價系統設計[J].軟 件,2015,36(4):119-122.
[14] ISO 26262 Road vehicles-Functional safety-Part 8: Supporting processes,2018.
[15] Slotosch O.Model-Based Tool Qualification[C]// International conference on software engineering and formal methods;International symposium on Innovation and sustainability in education;International symposium on modelling and knowledge management for sustainable development;International workshop.
