相對于功能安全概念階段，系統階段更專注于產品的詳細設計，涉及系統工程、安全工程和架構設計等不同技術領域。同時，系統階段也經常扮演著供應鏈上、下游功能安全的DIA交互階段，是功能安全中非常重要且考驗技術水平的階段。

01

應用環境

車載智能計算平臺，作為自動駕駛的主要部件，其應用環境參考如圖。



車載智能計算平臺應用環境參考示意圖

車載智能計算平臺的應用環境主要包含用于環境感知（如攝像頭、激光雷達、毫米波雷達、超聲波雷達等）和位置定位（如GNSS、高精度地圖等）的傳感器，整車底盤域、動力域以及車身域的執行器，人機交互的HMI，以及外部互聯與通信的T-Box和OBD等。隨著自動駕駛等級的不斷提高，車載智能計算平臺對應用環境中的傳感器、執行器、人機接口和外部互聯通信有更高的功能要求及功能安全要求。

02

功能劃分

車載智能計算平臺按照功能可以分為傳感器接入及管理、AI計算、通用計算、通信、存儲和車控等。不同的功能依賴不同的系統模塊實現。傳感器接入與管理單元提供豐富的軟硬件接口，使能傳感器接入及管理。AI計算提供深度神經網絡算法加速計算能力。通用計算主要是指面向常規算法的計算能力。

車載智能計算平臺內部通信提供車載智能計算平臺內部各個要素之間通信能力。V2X通信提供車載智能計算平臺連接車輛外部設備能力。存儲功能提供諸如高精度地圖存儲及服務能力。車控提供車控下發能力，對接車輛執行器。



車載智能計算平臺功能單元參考ASIL等級

03

安全分析

系統安全分析的目的是識別功能或系統設計中存在的違背安全目標的失效（包括單點失效或異常）和相關性失效（如共因失效和級聯失效）等。ISO 26262對此提及兩種安全分析方法：

歸納分析（Inductive analysis）：是一種以自上向下的分析方式，從已知影響結果入手逐步向下分析找到失效原因的方法；

演繹分析（Deductive analysis）：是一種以自下而上的分析方式，從已知的失效原因入手推導出影響結果的方法。

演繹分析方法是針對ASIL等級為C/D的功能安全開發所使用的方法，具體常用的方法有故障樹分析（FTA）、可靠框圖（RBD）、系統理論與過程分析（STPA）等。歸納分析方法是針對所有ASIL等級的功能安全開發都強烈推薦使用的方法，具體常用的方法有失效模式與影響分析（FMEA）和事件樹分析（ETA）等。

另外，安全分析包括定量分析與定性分析，在系統階段的安全分析用于輔助系統設計，因此，這個階段定性的安全分析就足夠了。在系統階段的安全分析過程中，除了上面提及的分析方法，還包括危險和可操作性分析（HAZOP）、接口安全分析（ISA）。

04

安全策略

自動駕駛功能目前的系統安全策略大體分為兩種，即Fail-Safe（失效-安全）以及Fail-Operational（失效-可操作）。Fail-Safe要求系統監控關鍵的部件以達到失效后系統關斷的目的。但是對于L3及以上的功能，駕駛員處于脫眼、脫手的狀態，系統的關閉并不能保證可靠地完成駕駛權的轉移。

例如，高速公路場景中，車輛緊急停止在本車道是一種潛在的風險狀態，很容易發生高速追尾。Fail-Operational安全策略解決了這一問題，即使在主功能系統失效的情況下，仍然有備份系統可以保證車輛進行降級操作，讓車輛轉移到安全區域。

05

系統設計

系統安全架構，業內常使用的是E-Gas三層監控架構。E-Gas監控概念源于奧迪、寶馬、戴姆勒、保時捷、大眾等成員一起通過工作組的形式開展的針對復雜車載控制系統的安全監控架構設計指導性文檔，涉及系統架構、軟件和硬件的設計理念，廣泛應用于傳統燃油車和新能源汽車監控與診斷設計領域。

E-Gas監控概念的核心是三層安全架構設計。整體設計分為Level1、Level2和Level3，其定義如下：



E-Gas三層安全架構（帶鎖步核）

Level1：功能層，包括扭矩的解析、功能的診斷等，最直接的理解就是能夠實現設計基本功能的軟件及相關硬件資源的組合；

Level2：功能監控層，負責監控功能層的輸出結論，簡單理解來看，就是軟件的冗余校驗，但是，由于不想消耗太多資源及避免算法共因，所以基于功能結果的監控；

Level3：硬件監控層，負責確保Level1和Level2的運行的硬件環境是正常工作的，異常的運行環境會導致Level2的設計起不到很好效果，因此，Level3在整體的監控架構中作用是不可替代的。

車載智能計算平臺的安全策略可以是獨立的監控模塊或冗余的系統設計。獨立的監控模塊實時監控功能實現模塊的軟硬件故障，一旦檢測到有安全相關故障，車輛即進入安全狀態，如需要可先進入緊急運行模式（Emergency Operation）。例如，功能降級、當前車道停車、安全地點停車等。

冗余的系統設計是指兩個或多個功能模塊互為備份。例如，車載智能計算平臺可以采用“主處理單元+輔處理單元”雙處理架構，以確保L3及以上自動駕駛車輛的安全。在該架構下，主處理單元對車輛的運動軌跡進行規劃和控制，輔處理單元的作用是監控主處理單元。同時兩個單元不斷地進行交叉檢查，當兩個通道在規劃軌跡和控制策略存在較大偏差時，系統就會進入降級模式。主處理單元和輔處理單元可以按照ASIL-B設計開發，仲裁模塊可以按照ASIL-D設計開發。

在系統階段進行設計時，需要考慮不同系統單元的故障以及對應的處理策略，具體包括傳感器接入能力失效，比如丟幀、亂序等；通用計算能力或AI計算能力失效，比如代碼跑飛、執行超時等；內部或V2X通信能力失效，比如超時等；存儲失效，比如高精度地圖數據損壞等；車控失效，比如非預期發送車控等；電源失效；時鐘失效。

06

技術安全概念

技術安全概念是車載智能計算平臺系統設計中安全策略與安全設計的集合。技術安全概念的內容主要包含基于系統架構的功能安全分析，基于上級功能安全要求與功能安全分析導出的技術安全要求，最終集成安全設計的系統架構，以及后續生產過程中需要采取的安全措施。

技術安全要求需要定義具體的安全機制并分配到相應的架構要素中，以確保在下一級的開發過程中，安全機制可以被進一步細化與實施。在車載智能計算平臺的開發過程中，技術安全概念可能針對于某一系統或子系統，因而技術安全要求涉及的架構層級可以不止一層。 功能安全概念規定了系統的安全目標，以及系統所需要的安全功能以實現這些安全目標。而技術安全概念則需要實現以下兩部分內容：

①進一步細化安全概念提出的安全功能，也就是從做什么轉化為怎么做，得出安全功能的實現技術方案；

②分析安全功能的實現路徑，找到系統或技術方案中引起安全功能失效的單點故障、潛伏故障和多點故障，并提出安全措施或安全機制來覆蓋這些故障。

具體而言，從功能安全需求（FSR，Functional Safety Requirement）/功能安全概念（FSC，Functional Safety Concept）導出到技術安全需求（TSR，Technical Safety Requirement）以及技術安全概念（TSC, Technical Safety Concept）的步驟如下：

步驟1：針對每一條FSR/FSC，詳細制訂該條FSR/FSC的實現技術方案，也可以理解為FSR/FSC在系統初始架構要素中的功能執行路徑，從傳感器→控制器→執行器的實現路徑；

步驟2：FSR/FSC的實現技術方案為對象，進行FTA或FMEA分析，識別出該實現技術方案中違背該條FSR/FSC的單點故障和雙點故障；

步驟3：針對單點故障，設計相應的具體診斷機制或安全措施；

步驟4：針對雙點故障，設計相應的避免潛伏故障的診斷機制或安全措施；

步驟5：匯總上述技術實現方案、針對單點的診斷機制和避免潛伏的診斷機制，形成TSR；

步驟6：將導出的TSR分配到具體實現要素如硬件和軟件，優化系統架構設計，即TSC；

步驟7：針對較復雜或多層系統，可重復步驟1—6過程進行迭代設計，直至完成整個系統的TSR/TSC開發。

在車載智能計算平臺的技術安全要求中，若采取多層次的技術安全要求，其基本原則不變，即技術安全要求要與架構層級相映射并最終被分配到軟件與硬件中，以保證軟件與硬件的功能安全開發有明確和完整的輸入。

07

測試驗證

系統測試內容與方法從軟硬件層面、系統層面與整車層面提出了要求，相應的測試內容、測試方法以及ASIL等級要求如表。



系統測試內容與方法列表

車載智能計算平臺在功能安全概念階段開發或假設了上層的安全目標和功能安全要求，安全要求在之后各個階段被逐漸細化和實現。最終完成硬件層面及軟件層面開發和集成的車載智能計算平臺能否正確實現安全要求，以及是否存在非預期的功能，需要通過系統層面的集成測試進行驗證。系統層面的測試驗證，一方面需要確保安全要求能夠被正確地使能，另一方面還需要確保車載智能計算平臺不會因為安全要求非預期使能而導致系統可用性降低。

制定有序的系統層面測試計劃，并進行持續的過程跟蹤管理，是保障車載智能計算平臺測試驗證工作有序可靠進行的必要途徑。開發測試團隊應重點考慮項目整體時間計劃、測試驗證的人員安排與責任分工、測試方法、測試環境、測試工具等方面的內容，綜合評估和確認之后形成測試計劃。

基于SEooC模式開發的車載智能計算平臺實際應用到目標車型時，系統集成測試和整車集成測試是發現系統性故障不可或缺的安全活動。在系統集成測試和整車集成測試活動中，需重點驗證目標車型的功能安全要求是否得到正確實現，集成真實的傳感器和執行器等其他其它要素之后的系統響應是否滿足安全機制的要求，車載智能計算平臺與目標車型其他要素之間的接口與交互過程是否正確，以及安全要求在外界嚴苛的環境條件和運行工況下能否正常實現。

08

系統開發常用工具介紹

依據ISO26262的要求，為實現系統設計滿足如圖所示的原則，一般可使用半形式化如SysML語言+自然語言實現。行業內用得比較多的、支持系統設計的工具有Medini Analyze、IBM Rhapsody和Enterprise architect等。Medini Analyze與ISO 26262要求更加契合，IBM Rhapsody和Enterprise architect的系統工程建模則更加強大。



系統設計原則

a、Medini Analyze

Medini Analyze是Ansys公司開發的一款支持ISO26262開發活動的工具，它提供一系列綁定在模型化環境中的先進分析方法，包括：

?針對電子電氣系統和軟件控制功能的安全分析和設計，以及適用于ISO26262、IEC61508、ARP4761和MIL-STD-882E的特定模板；

?將架構/功能設計與質量、可靠性和功能安全分析方法進行集成；

?可支持運行情境分析、危險與風險分析（HARA）、功能性風險評估（FHA）、FTA、FMEA、FMEDA、FMECA概率可靠性分析以及硬件失效指標；

?依照SAEJ1739、VDA質量手冊、AIAG等標準進行產品設計及相關流程的質量分析；

?完整的端到端可追溯功能；

?工作成果和文檔的定制化生成；

?團隊協作支持，包含模型化高級對比和合并技術；

?集成Ansys SCADE Architect、IBM Rational DOORS、IBM Rational Rhapsody、Enterprise Architect、MATLAB/Simulink、State flow、PTC Integrity、Microsoft Office、Tortoise SVN、IBM Rational ClearCase、Jama Software等工具。



Medini Analyze驅動集成安全分析

b、IBM Rhapsody

IBM Rhapsody是IBM公司基于UML/SysML的模型驅動開發集成環境，用于嵌入式和實時系統的系統設計開發工具。

Rhapsody的主要功能如下：

?使用行業標準建模語言：UML、SysML、DoDAF等；

?支持可視化模型仿真；

?支持C、C++、Java等語言開發環境，做到模型平臺無關性；

?支持常用的嵌入式實時操作系統，如VxWorks、嵌入式Linux、Android、OSEK、QNX等；

?基于Jazz平臺與DOORS、RTC、RQM無縫集成。

c、Enterprise architect

Enterprise architect是Sparx Systems公司的旗艦產品。它覆蓋了系統開發的整個周期，除了開發類模型之外，還包括事務進程分析、使用案例需求、動態模型、組件和布局、系統管理、非功能需求、用戶界面設計、測試和維護等。該工具特點：

?高價值、端到端的建模，支持軟件和系統工程的完整的建模生命周期；

?建模、管理和跟蹤需求；

??強大的文檔生成能力；

?源代碼的生成和反向工程；

?先進的模型驅動架構，包括C#、DDL、EJB、Java、Junit、NUnit、WSDL、XSD的建模轉化；

?支持SysML系統工程和仿真；

?業務流程建模；

?基于UML2.4.1語言；

?高效的項目管理；

審核編輯：劉清