求一種基于功能安全的車載計(jì)算平臺(tái)系統(tǒng)開發(fā)方案

相對(duì)于功能安全概念階段，系統(tǒng)階段更專注于產(chǎn)品的詳細(xì)設(shè)計(jì)，涉及系統(tǒng)工程、安全工程和架構(gòu)設(shè)計(jì)等不同技術(shù)領(lǐng)域。同時(shí)，系統(tǒng)階段也經(jīng)常扮演著供應(yīng)鏈上、下游功能安全的DIA交互階段，是功能安全中非常重要且考驗(yàn)技術(shù)水平的階段。

01

應(yīng)用環(huán)境

車載智能計(jì)算平臺(tái)，作為自動(dòng)駕駛的主要部件，其應(yīng)用環(huán)境參考如圖。



車載智能計(jì)算平臺(tái)應(yīng)用環(huán)境參考示意圖

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

02

功能劃分

車載智能計(jì)算平臺(tái)按照功能可以分為傳感器接入及管理、AI計(jì)算、通用計(jì)算、通信、存儲(chǔ)和車控等。不同的功能依賴不同的系統(tǒng)模塊實(shí)現(xiàn)。傳感器接入與管理單元提供豐富的軟硬件接口，使能傳感器接入及管理。AI計(jì)算提供深度神經(jīng)網(wǎng)絡(luò)算法加速計(jì)算能力。通用計(jì)算主要是指面向常規(guī)算法的計(jì)算能力。

車載智能計(jì)算平臺(tái)內(nèi)部通信提供車載智能計(jì)算平臺(tái)內(nèi)部各個(gè)要素之間通信能力。V2X通信提供車載智能計(jì)算平臺(tái)連接車輛外部設(shè)備能力。存儲(chǔ)功能提供諸如高精度地圖存儲(chǔ)及服務(wù)能力。車控提供車控下發(fā)能力，對(duì)接車輛執(zhí)行器。



車載智能計(jì)算平臺(tái)功能單元參考ASIL等級(jí)

03

安全分析

系統(tǒng)安全分析的目的是識(shí)別功能或系統(tǒng)設(shè)計(jì)中存在的違背安全目標(biāo)的失效（包括單點(diǎn)失效或異常）和相關(guān)性失效（如共因失效和級(jí)聯(lián)失效）等。ISO 26262對(duì)此提及兩種安全分析方法：

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

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

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

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

04

安全策略

自動(dòng)駕駛功能目前的系統(tǒng)安全策略大體分為兩種，即Fail-Safe（失效-安全）以及Fail-Operational（失效-可操作）。Fail-Safe要求系統(tǒng)監(jiān)控關(guān)鍵的部件以達(dá)到失效后系統(tǒng)關(guān)斷的目的。但是對(duì)于L3及以上的功能，駕駛員處于脫眼、脫手的狀態(tài)，系統(tǒng)的關(guān)閉并不能保證可靠地完成駕駛權(quán)的轉(zhuǎn)移。

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

05

系統(tǒng)設(shè)計(jì)

系統(tǒng)安全架構(gòu)，業(yè)內(nèi)常使用的是E-Gas三層監(jiān)控架構(gòu)。E-Gas監(jiān)控概念源于奧迪、寶馬、戴姆勒、保時(shí)捷、大眾等成員一起通過工作組的形式開展的針對(duì)復(fù)雜車載控制系統(tǒng)的安全監(jiān)控架構(gòu)設(shè)計(jì)指導(dǎo)性文檔，涉及系統(tǒng)架構(gòu)、軟件和硬件的設(shè)計(jì)理念，廣泛應(yīng)用于傳統(tǒng)燃油車和新能源汽車監(jiān)控與診斷設(shè)計(jì)領(lǐng)域。

E-Gas監(jiān)控概念的核心是三層安全架構(gòu)設(shè)計(jì)。整體設(shè)計(jì)分為L(zhǎng)evel1、Level2和Level3，其定義如下：



E-Gas三層安全架構(gòu)（帶鎖步核）

Level1：功能層，包括扭矩的解析、功能的診斷等，最直接的理解就是能夠?qū)崿F(xiàn)設(shè)計(jì)基本功能的軟件及相關(guān)硬件資源的組合；

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

Level3：硬件監(jiān)控層，負(fù)責(zé)確保Level1和Level2的運(yùn)行的硬件環(huán)境是正常工作的，異常的運(yùn)行環(huán)境會(huì)導(dǎo)致Level2的設(shè)計(jì)起不到很好效果，因此，Level3在整體的監(jiān)控架構(gòu)中作用是不可替代的。

車載智能計(jì)算平臺(tái)的安全策略可以是獨(dú)立的監(jiān)控模塊或冗余的系統(tǒng)設(shè)計(jì)。獨(dú)立的監(jiān)控模塊實(shí)時(shí)監(jiān)控功能實(shí)現(xiàn)模塊的軟硬件故障，一旦檢測(cè)到有安全相關(guān)故障，車輛即進(jìn)入安全狀態(tài)，如需要可先進(jìn)入緊急運(yùn)行模式（Emergency Operation）。例如，功能降級(jí)、當(dāng)前車道停車、安全地點(diǎn)停車等。

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

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

06

技術(shù)安全概念

技術(shù)安全概念是車載智能計(jì)算平臺(tái)系統(tǒng)設(shè)計(jì)中安全策略與安全設(shè)計(jì)的集合。技術(shù)安全概念的內(nèi)容主要包含基于系統(tǒng)架構(gòu)的功能安全分析，基于上級(jí)功能安全要求與功能安全分析導(dǎo)出的技術(shù)安全要求，最終集成安全設(shè)計(jì)的系統(tǒng)架構(gòu)，以及后續(xù)生產(chǎn)過程中需要采取的安全措施。

技術(shù)安全要求需要定義具體的安全機(jī)制并分配到相應(yīng)的架構(gòu)要素中，以確保在下一級(jí)的開發(fā)過程中，安全機(jī)制可以被進(jìn)一步細(xì)化與實(shí)施。在車載智能計(jì)算平臺(tái)的開發(fā)過程中，技術(shù)安全概念可能針對(duì)于某一系統(tǒng)或子系統(tǒng)，因而技術(shù)安全要求涉及的架構(gòu)層級(jí)可以不止一層。 功能安全概念規(guī)定了系統(tǒng)的安全目標(biāo)，以及系統(tǒng)所需要的安全功能以實(shí)現(xiàn)這些安全目標(biāo)。而技術(shù)安全概念則需要實(shí)現(xiàn)以下兩部分內(nèi)容：

①進(jìn)一步細(xì)化安全概念提出的安全功能，也就是從做什么轉(zhuǎn)化為怎么做，得出安全功能的實(shí)現(xiàn)技術(shù)方案；

②分析安全功能的實(shí)現(xiàn)路徑，找到系統(tǒng)或技術(shù)方案中引起安全功能失效的單點(diǎn)故障、潛伏故障和多點(diǎn)故障，并提出安全措施或安全機(jī)制來覆蓋這些故障。

具體而言，從功能安全需求（FSR，F(xiàn)unctional Safety Requirement）/功能安全概念（FSC，F(xiàn)unctional Safety Concept）導(dǎo)出到技術(shù)安全需求（TSR，Technical Safety Requirement）以及技術(shù)安全概念（TSC, Technical Safety Concept）的步驟如下：

步驟1：針對(duì)每一條FSR/FSC，詳細(xì)制訂該條FSR/FSC的實(shí)現(xiàn)技術(shù)方案，也可以理解為FSR/FSC在系統(tǒng)初始架構(gòu)要素中的功能執(zhí)行路徑，從傳感器→控制器→執(zhí)行器的實(shí)現(xiàn)路徑；

步驟2：FSR/FSC的實(shí)現(xiàn)技術(shù)方案為對(duì)象，進(jìn)行FTA或FMEA分析，識(shí)別出該實(shí)現(xiàn)技術(shù)方案中違背該條FSR/FSC的單點(diǎn)故障和雙點(diǎn)故障；

步驟3：針對(duì)單點(diǎn)故障，設(shè)計(jì)相應(yīng)的具體診斷機(jī)制或安全措施；

步驟4：針對(duì)雙點(diǎn)故障，設(shè)計(jì)相應(yīng)的避免潛伏故障的診斷機(jī)制或安全措施；

步驟5：匯總上述技術(shù)實(shí)現(xiàn)方案、針對(duì)單點(diǎn)的診斷機(jī)制和避免潛伏的診斷機(jī)制，形成TSR；

步驟6：將導(dǎo)出的TSR分配到具體實(shí)現(xiàn)要素如硬件和軟件，優(yōu)化系統(tǒng)架構(gòu)設(shè)計(jì)，即TSC；

步驟7：針對(duì)較復(fù)雜或多層系統(tǒng)，可重復(fù)步驟1—6過程進(jìn)行迭代設(shè)計(jì)，直至完成整個(gè)系統(tǒng)的TSR/TSC開發(fā)。

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

07

測(cè)試驗(yàn)證

系統(tǒng)測(cè)試內(nèi)容與方法從軟硬件層面、系統(tǒng)層面與整車層面提出了要求，相應(yīng)的測(cè)試內(nèi)容、測(cè)試方法以及ASIL等級(jí)要求如表。



系統(tǒng)測(cè)試內(nèi)容與方法列表

車載智能計(jì)算平臺(tái)在功能安全概念階段開發(fā)或假設(shè)了上層的安全目標(biāo)和功能安全要求，安全要求在之后各個(gè)階段被逐漸細(xì)化和實(shí)現(xiàn)。最終完成硬件層面及軟件層面開發(fā)和集成的車載智能計(jì)算平臺(tái)能否正確實(shí)現(xiàn)安全要求，以及是否存在非預(yù)期的功能，需要通過系統(tǒng)層面的集成測(cè)試進(jìn)行驗(yàn)證。系統(tǒng)層面的測(cè)試驗(yàn)證，一方面需要確保安全要求能夠被正確地使能，另一方面還需要確保車載智能計(jì)算平臺(tái)不會(huì)因?yàn)榘踩蠓穷A(yù)期使能而導(dǎo)致系統(tǒng)可用性降低。

制定有序的系統(tǒng)層面測(cè)試計(jì)劃，并進(jìn)行持續(xù)的過程跟蹤管理，是保障車載智能計(jì)算平臺(tái)測(cè)試驗(yàn)證工作有序可靠進(jìn)行的必要途徑。開發(fā)測(cè)試團(tuán)隊(duì)?wèi)?yīng)重點(diǎn)考慮項(xiàng)目整體時(shí)間計(jì)劃、測(cè)試驗(yàn)證的人員安排與責(zé)任分工、測(cè)試方法、測(cè)試環(huán)境、測(cè)試工具等方面的內(nèi)容，綜合評(píng)估和確認(rèn)之后形成測(cè)試計(jì)劃。

基于SEooC模式開發(fā)的車載智能計(jì)算平臺(tái)實(shí)際應(yīng)用到目標(biāo)車型時(shí)，系統(tǒng)集成測(cè)試和整車集成測(cè)試是發(fā)現(xiàn)系統(tǒng)性故障不可或缺的安全活動(dòng)。在系統(tǒng)集成測(cè)試和整車集成測(cè)試活動(dòng)中，需重點(diǎn)驗(yàn)證目標(biāo)車型的功能安全要求是否得到正確實(shí)現(xiàn)，集成真實(shí)的傳感器和執(zhí)行器等其他其它要素之后的系統(tǒng)響應(yīng)是否滿足安全機(jī)制的要求，車載智能計(jì)算平臺(tái)與目標(biāo)車型其他要素之間的接口與交互過程是否正確，以及安全要求在外界嚴(yán)苛的環(huán)境條件和運(yùn)行工況下能否正常實(shí)現(xiàn)。

08

系統(tǒng)開發(fā)常用工具介紹

依據(jù)ISO26262的要求，為實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)滿足如圖所示的原則，一般可使用半形式化如SysML語(yǔ)言+自然語(yǔ)言實(shí)現(xiàn)。行業(yè)內(nèi)用得比較多的、支持系統(tǒng)設(shè)計(jì)的工具有Medini Analyze、IBM Rhapsody和Enterprise architect等。Medini Analyze與ISO 26262要求更加契合，IBM Rhapsody和Enterprise architect的系統(tǒng)工程建模則更加強(qiáng)大。



系統(tǒng)設(shè)計(jì)原則

a、Medini Analyze

Medini Analyze是Ansys公司開發(fā)的一款支持ISO26262開發(fā)活動(dòng)的工具，它提供一系列綁定在模型化環(huán)境中的先進(jìn)分析方法，包括：

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

?將架構(gòu)/功能設(shè)計(jì)與質(zhì)量、可靠性和功能安全分析方法進(jìn)行集成；

?可支持運(yùn)行情境分析、危險(xiǎn)與風(fēng)險(xiǎn)分析（HARA）、功能性風(fēng)險(xiǎn)評(píng)估（FHA）、FTA、FMEA、FMEDA、FMECA概率可靠性分析以及硬件失效指標(biāo)；

?依照SAEJ1739、VDA質(zhì)量手冊(cè)、AIAG等標(biāo)準(zhǔn)進(jìn)行產(chǎn)品設(shè)計(jì)及相關(guān)流程的質(zhì)量分析；

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

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

?團(tuán)隊(duì)協(xié)作支持，包含模型化高級(jí)對(duì)比和合并技術(shù)；

?集成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驅(qū)動(dòng)集成安全分析

b、IBM Rhapsody

IBM Rhapsody是IBM公司基于UML/SysML的模型驅(qū)動(dòng)開發(fā)集成環(huán)境，用于嵌入式和實(shí)時(shí)系統(tǒng)的系統(tǒng)設(shè)計(jì)開發(fā)工具。

Rhapsody的主要功能如下：

?使用行業(yè)標(biāo)準(zhǔn)建模語(yǔ)言：UML、SysML、DoDAF等；

?支持可視化模型仿真；

?支持C、C++、Java等語(yǔ)言開發(fā)環(huán)境，做到模型平臺(tái)無關(guān)性；

?支持常用的嵌入式實(shí)時(shí)操作系統(tǒng)，如VxWorks、嵌入式Linux、Android、OSEK、QNX等；

?基于Jazz平臺(tái)與DOORS、RTC、RQM無縫集成。

c、Enterprise architect

Enterprise architect是Sparx Systems公司的旗艦產(chǎn)品。它覆蓋了系統(tǒng)開發(fā)的整個(gè)周期，除了開發(fā)類模型之外，還包括事務(wù)進(jìn)程分析、使用案例需求、動(dòng)態(tài)模型、組件和布局、系統(tǒng)管理、非功能需求、用戶界面設(shè)計(jì)、測(cè)試和維護(hù)等。該工具特點(diǎn)：

?高價(jià)值、端到端的建模，支持軟件和系統(tǒng)工程的完整的建模生命周期；

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

??強(qiáng)大的文檔生成能力；

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

?先進(jìn)的模型驅(qū)動(dòng)架構(gòu)，包括C#、DDL、EJB、Java、Junit、NUnit、WSDL、XSD的建模轉(zhuǎn)化；

?支持SysML系統(tǒng)工程和仿真；

?業(yè)務(wù)流程建模；

?基于UML2.4.1語(yǔ)言；

?高效的項(xiàng)目管理；

審核編輯：劉清