自動駕駛硬件功能安全面臨的挑戰(zhàn)

楊莉 董昊旻 隋建鵬

（1.中國第一汽車股份有限公司 智能網(wǎng)聯(lián)開發(fā)院，長春 130013；2.中國第一汽車股份有限公司 研發(fā)總院，長春130013）

主題詞：ISO 26262 硬件功能安全 自動駕駛

縮略語

DV Design Validation

HSR Hardware Safety Requirement

DFMEA Design Failure Mode and Effects Analysis

FTA Fault Tree Analysis

ASIL Automotive Safety Integration Level

FMEDA Failure Mode Effects and Diagnostic Analysis

HARA Hazard Assessment by Risk Analysis

SG Safety Goal

LFM Latent Failure Matric

SPFM Single Point Failure Matric

PMHF Probability Metric for Random Hardware Failures

BOM Bill of Material

FIT Fault Injection Test

GPU Graphics Processing Unit

FPGA Field-Programmable Gate Array

ASIC Application Specific Integrated Circuit

1 前言

在過去的十年中，針對自動駕駛汽車的研究和應用呈現(xiàn)了爆發(fā)式的增長，大量的自動駕駛相關基礎技術越來越成熟。目前，以戴姆勒、寶馬、奧迪、福特、東風日產(chǎn)、沃爾沃、上汽、一汽為代表的國內(nèi)外主流整車廠都在進行自動駕駛相關領域技術的研發(fā)，每年的國際消費類電子產(chǎn)品展覽會（CES：International Consumer Electronics Show）上，可以看到越來越多的自動駕駛樣車的演示[1]。有理由相信顛覆性的自動駕駛技術將帶來交通和移動出行領域的又一次重大變革。

然而，隨著算法復雜度的增加和自動駕駛等級的提高，安全性成為了影響自動駕駛汽車真正落地的重要阻礙。2011年，作為汽車行業(yè)專用的功能安全標準，ISO 26262應運而生。ISO 26262為汽車生產(chǎn)商提供了一整套系統(tǒng)的設計方法來識別危險源，提升汽車的安全性。

ISO 26262標準包含概念層面、系統(tǒng)層面、硬件層面、軟件層面、管理層面等部分，本文僅重點針對硬件層面，分析硬件功能安全開發(fā)與傳統(tǒng)汽車電子電氣硬件開發(fā)的融合，并基于此，提出自動駕駛汽車計算平臺硬件功能安全開發(fā)面臨的風險和挑戰(zhàn)。

2 硬件功能安全開發(fā)與傳統(tǒng)硬件開發(fā)的融合

隨著汽車電動化、智能化、網(wǎng)聯(lián)化、共享化的程度越來越高，汽車電子模塊也越來越多，為整車的性能提升和用戶體驗發(fā)揮著巨大的作用。汽車電子的硬件設計不同于通訊電子、工業(yè)電子和消費類電子的硬件設計，需要特殊考慮汽車電子的使用環(huán)境[2]。汽車電子的氣候條件、機械條件和電氣條件都要比通訊電子、工業(yè)電子和消費類電子的使用環(huán)境更惡劣。在電子產(chǎn)品隨車使用時，汽車的使用環(huán)境條件很大程度上影響著電子產(chǎn)品的功能、性能和壽命。在汽車電子硬件設計開發(fā)過程中，首先要清楚這些條件和邊界，其次要在設計過程中考慮這些因素，最后在模擬這些條件的實驗中進行檢驗。

由于汽車電子特殊的使用環(huán)境，對硬件設計提出了更高的要求。為了保證汽車在使用環(huán)境下的整車性能，傳統(tǒng)的汽車電子硬件設計流程如圖1所示，硬件設計的職責從項目啟動開始，到生產(chǎn)流程審核結(jié)束，包括計劃制定、需求分析、方案設計、硬件設計及測試、設計驗證（DV：Design Validation）、生產(chǎn)準備。

ISO 26262標準2011版本第5章[3]對硬件功能安全開發(fā)流程推薦如圖2所示。硬件功能安全開發(fā)承接系統(tǒng)設計的輸出物，并通過硬件板級測試對硬件元器件進行質(zhì)量認可，提交輸出物給生產(chǎn)、運行維護及系統(tǒng)集成測試。注意，標準中推薦的硬件功能安全開發(fā)流程只是概況，并不詳細，與實際硬件開發(fā)中執(zhí)行的開發(fā)流程有一定差距。

圖1 傳統(tǒng)汽車電子硬件設計流程

圖2 ISO 26262推薦的硬件功能安全開發(fā)流程[3]

結(jié)合項目實際開發(fā)流程，將傳統(tǒng)的汽車電子硬件開發(fā)流程與功能安全進行了融合，得到了符合功能安全的硬件開發(fā)流程，如圖3所示。

由圖3可見，功能安全貫穿于整個硬件開發(fā)流程中。融合后的汽車電子硬件功能安全開發(fā)流程從功能安全的角度對傳統(tǒng)的汽車電子硬件開發(fā)流程進行了完善和補充。

完善和補充體現(xiàn)在以下幾個方面：

（1）項目計劃中，新建功能安全開發(fā)計劃，統(tǒng)籌管理整個項目中的功能安全開發(fā)工作，包括工作內(nèi)容、工作起始/結(jié)束時間、責任人、輸入條件、提交物等；

（2）在進行需求分析時，除了考慮傳統(tǒng)硬件開發(fā)的需求外，還需要考慮功能安全需求。每一條硬件需求均需要關聯(lián)ASIL（Automotive Safety Integration Level）等級，非功能安全相關的需求ASIL等級為QM。形成硬件安全需求文檔，并進行設計團隊內(nèi)部評審。

（3）在方案設計階段，需要充分考慮為了滿足功能安全需求而需要進行的復位邏輯設計、看門狗電路模塊設計、電源監(jiān)控設計、輔監(jiān)控單片機模塊設計等。

圖3 功能安全硬件開發(fā)流程

（4）硬件設計階段，需要開展設計失效模式及后果分析（DFMEA：Design Failure Mode and Effects Analysis）、故障樹分析（FTA：Fault Tree Analysis）、失效模式影響及診斷分析（FMEDA：Failure Mode Effects and Diagnostic Analysis）等分析工作。其中FTA只在ASIL等級為C或D時開展，F(xiàn)MEDA只在ASIL等級為B或C或D時開展。同時在該階段還需要編寫軟硬件接口文檔和硬件設計規(guī)范文檔。硬件測試階段，針對ASIL C或D等級的系統(tǒng)需要開展故障注入測試。

（5）在設計驗證和生產(chǎn)準備階段，均需要額外考慮不同的功能安全等級對測試深度、測試方法、測試標準的不同要求。

根據(jù)不同的地質(zhì)條件、潮汐風浪等環(huán)境因素，對具有相同建設條件、有代表性的燈樁進行設計（包括基礎選擇、選材、作用、尺寸、樓梯設計），以此為依據(jù)編制燈樁標準化設計施工圖紙。

3 自動駕駛硬件功能安全開發(fā)面臨的挑戰(zhàn)

自動駕駛的初衷是保證道路參與者的生命安全，功能安全是讓自動駕駛比手動駕駛更安全的基本保障之一。然而ISO 26262的最新版本[4]并不完全適用于自動駕駛相關控制器的功能安全[5]。

首先，按照SAE J3016道路車輛自動駕駛系統(tǒng)分類和定義[6]，將自動駕駛技術等級分為6級，分別為0級-5級。L4級及以上的自動駕駛系統(tǒng)中，駕駛員將不再接管對車輛的控制權。傳統(tǒng)的功能安全中失效安全（fail-safe）的實現(xiàn)手段取決于駕駛員能夠控制車輛，并使車輛進入安全狀態(tài)。因此對于自動駕駛汽車的功能安全要求變?yōu)槭Э晒ぷ鳎╢ail-operational）[7]。其次，ISO 26262是以相關項為導向，這意味著一個駕駛功能是通過一個運行于硬件系統(tǒng)上的軟件系統(tǒng)來實現(xiàn)的。然而自動駕駛來的發(fā)展趨勢是在一個域控制器上實現(xiàn)多個駕駛功能。這種架構(gòu)使得ISO 26262中強調(diào)的“互相獨立”概念很難實現(xiàn)。最后，自動駕駛中深度學習算法帶來的不確定性和非線性使得傳統(tǒng)的失效分析方法不再適用。

基于上述幾點，本節(jié)主要分析硬件功能安全開發(fā)在自動駕駛領域面臨的挑戰(zhàn)。

3.1 輸入條件不明確

硬件功能安全設計的根本依據(jù)是系統(tǒng)層危害分析和風險評估（Hazard Assessment by Risk Analysis，HARA）分析輸出的安全目標（Safety Goal，SG）。根據(jù)ISO 26262標準，危害的定義是基于對工作情況的分析而開展的。工作情況包括運行條件和工作狀態(tài)。這意味著，HARA分析通常包含很多區(qū)別很小的工作情況。將自動駕駛的駕駛參數(shù)適配到如此細化的工作狀態(tài)中，工作量是很大的，有時甚至是不可能完成的。同時對如此復雜的工作情況進行管理也是存在問題的[8]。另外，不管是采用機器學習，還是深度學習，都存在一定的不確定性。這種不確定性導致不同的網(wǎng)絡參數(shù)情況有可能具有不同的安全目標，很難得出一個確定的可以實施的安全目標[9]。這對硬件功能安全開發(fā)的影響可以說是巨大的，沒有了明確的依據(jù)，硬件功能安全開發(fā)將舉步維艱。

3.2 ASIL等級較高

在傳統(tǒng)汽車開發(fā)中，人、車和路三個要素組成一個封閉的在環(huán)系統(tǒng)。其中，人指的就是駕駛員。對于自動駕駛等級L3以上的系統(tǒng)，駕駛員不再是這個系統(tǒng)中的要素。當駕駛員不在環(huán)的情況下，可控性面臨巨大挑戰(zhàn)。在ISO 26262標準中，可控性是直接決定ASIL等級的三要素之一[10]。駕駛員對車輛的可控性能越差，可控性參數(shù)分值（Controllability）越高。行業(yè)內(nèi)正在探討除了ASIL D之外是不是上面還應該有個更高的層次。依據(jù)ISO 26262標準，ASIL C或ASIL D意味著無論是從硬件開發(fā)流程還是硬件設計工作的復雜性來講，都必須滿足更高的要求。如果是ASIL D以上，還需要一個更高的層級，那么硬件開發(fā)工作的工作量和復雜度不可估量。

3.3 硬件架構(gòu)復雜

傳統(tǒng)的汽車電子電氣架構(gòu)已經(jīng)很難滿足自動駕駛應用中對計算性能、軟件升級、關鍵信息高速高效處理的需求，比如攝像頭、毫米波雷達、激光雷達乃至GPS（Global Positioning System）的數(shù)據(jù)都需要在一個計算中心內(nèi)進行處理以保證輸出結(jié)果對整車自動駕駛性能最優(yōu)。新興的整車域集中式電子電氣架構(gòu)如圖4[11]所示。

由圖4可見，根據(jù)汽車電子部件的功能將整車劃分為駕駛輔助、車輛安全、車輛運動、娛樂信息、車身電子等幾個域。域控制器的核心發(fā)針時芯片計算能力的提升?；谡囉蚣惺诫娮与姎饧軜?gòu)概念的提出，域控制器硬件架構(gòu)更復雜。

圖4 整車域集中式電子電氣架構(gòu)圖[11]

硬件架構(gòu)復雜度的提升主要體現(xiàn)在以下幾個方面。

（1）計算能力高，功耗大，散熱問題突出；

（2）數(shù)據(jù)吞吐率高，板內(nèi)通信速率高，信號完整性問題顯著；

（3）板內(nèi)供電時序復雜。

典型的自動駕駛域控制器硬件架構(gòu)如圖5[12]所示。該架構(gòu)中尚未充分考慮功能安全，如何設計出滿足系統(tǒng)功能安全等級需求的完整架構(gòu)還有待探索和實踐。

圖5 典型域控制器硬件架構(gòu)[12]

3.4 上游芯片功能安全開展不成熟

由于自動駕駛高算力和低功耗的強烈需求，傳統(tǒng)控制芯片已不能滿足該領域的應用需求。目前，應用于L3以上自動駕駛領域的主控制芯片主要分為三類：GPU（Graphics Processing Unit）、FPGA（Field-Programmable Gate Array）和專用ASIC（Application Specific Integrated Circuit）。GPU以英偉達公司的PX2平臺為代表，F(xiàn)PGA以Xilinx公司的ZYNQ系列為代表，專用ASIC以地平線公司的征程系列為代表。以上三類主控制芯片在架構(gòu)上均不同于傳統(tǒng)的控制芯片，在車載領域的應用尚不成熟，對功能安全的開展更不成熟。該三類芯片的供應商很少能夠提供完善的芯片級功能安全手冊及芯片級FMEDA分析結(jié)果，不利于板級硬件功能安全的開發(fā)。

3.5 硬件功能安全分析工作量巨大

對于硬件的安全分析，計算的結(jié)果作為失效隨機發(fā)生的可能性考慮。這些失效可能是僅發(fā)生一次，也可能是永久發(fā)生。發(fā)生的可能性通過FIT值來表征，1FIT意味著在109小時內(nèi)發(fā)生1次。硬件功能安全關注點在于限制失效的發(fā)生及/或防止危害安全目標。

硬件功能安全分析包含兩部分。第一部分是硬件架構(gòu)可靠性的分析，是否存在冗余機制及診斷覆蓋率的數(shù)值決定潛在失效度量(LFM)或單點故障度量(SPFM)的計算結(jié)果。另一部分是對于特定安全目標產(chǎn)生危害的可能性，通過硬件隨機失效率(PMHF)來表征。對于不同的功能安全等級，上述三個度量的可接受限值如表1所示。

表1 ISO 26262功能安全等級評估指標表

潛在失效度量和單點失效度量通過FMEDA計算得到結(jié)果，硬件隨機失效率通過FMEDA或FTA計算得到結(jié)果。無論是FMEDA還是FTA，均需要針對每個安全目標分析所有BOM（Bill of Material）中元器件。因此，安全目標和BOM中元器件數(shù)量及復雜度的增加意味著工作量成倍數(shù)的增長。

3.6 硬件測試難度增加

ISO 26262中明確規(guī)定，對于ASIL C/D的電子電氣系統(tǒng)需要進行故障注入測試（Fault Injection Test）。硬件故障注入測試的目的是驗證硬件元器件發(fā)生隨機故障時，軟件是否可以診斷出相應的故障。該測試要求覆蓋板內(nèi)所有元器件的所有隨機失效模式。自動駕駛電子電器系統(tǒng)的板內(nèi)元器件眾多，且主處理芯片的引腳數(shù)目動輒成百上千，每個元器件的每個引腳在均需要注入開路、短路的故障。同時，需要基礎軟件開發(fā)配合實現(xiàn)該測試，將診斷到的故障上報到測試操作界面并存儲到測試日志文件（log文件）。由此帶來的工作量和開發(fā)難度可想而知。

4 結(jié)論及啟示

隨著國內(nèi)外整車廠、科技公司、新創(chuàng)公司自動駕駛業(yè)務如火如荼的開展，針對如何將ISO 26262標準應用到自動駕駛領域的思考和研究逐漸提上日程。然而目前尚未有明確的標準或草案出臺。

作為決定整車自動駕駛性能關鍵一環(huán)的電子電氣系統(tǒng)硬件設計來說，有責任和義務進一步考慮到將功能安全應用于自動駕駛電子電氣硬件設計存在的問題和挑戰(zhàn)。明晰問題和挑戰(zhàn)對我們實際開展硬件設計工作具有指導意義。