一、目前市場上主流的ADAS解決方案大體分為兩種：

1.以Mobileye為首的使用采用Smart Sensor的解決方案，即在Sensor ECU給出識別對象信息，給到ADAS ECU做決策與執行機構控制。

2.以Aptiv等Tier1為主導的域控制器方案，攝像頭激光雷達直接傳遞Raw Data給到域控制器，域控制器進行決策并控制執行機構。

方案一：

在整車電子電器架構的設計上相比方案二較為簡單，傳感器供應商可以直接通過CAN通訊給出車輛執行機構所需要的信息，以傳統攝像頭模組搭配CAN通訊的組合可以很輕松的達到ASIL B的等級，但由于單一傳感器在探測能力上面的局限性，對于Level3以上的功能如高速公路自動駕駛、城鎮自動駕駛等復雜場景來講本方案在乘用車上難以落地。

方案二：

以域控制器為自動駕駛大腦的解決方案在奧迪新款zFAS平臺上大放異彩，作為全球第一款量產Level3車型，TTTech & Mobileye & Aptiv對該域控制器做出了大量貢獻。同時該產品的面世也證明了域控制器將為高階自動駕駛功能的實現提供技術支持和安全保障。在此膜拜Aptiv！

這里補充一個對于CAN通訊的解釋，在Ethernet通訊如此火熱的今天為什么還要在ADAS系統上繼續選擇CAN通訊？CAN FD是否將被使用？

答：對于ASIL B以上的安全要求，在架構上傳統的Ethernet不足以符合要求，目前各大廠家采用的傳感器通訊解決方案大多為Maxim的GMSL或傳統CAN。CAN FD將會在下一代量產車型中被使用。根據CiA(CAN in Automation)主席Holger Zeltwanger先生的預測，CAN FD的商用將于2022年初步實現。

二、域控制器解決方案功能安全分析

ISO26262-4 5 6分別對系統、軟件、硬件做出了詳細的設計與驗證規范，下面將以這三個維度對域控制器方案做進一步分析。

系統方面：

在系統架構上，域控制器作為整車電子電器中的一員，與其他ECU在安全等級上ASIL D的要求并無二致，在量產車的解決方案上對上承接Conti，Dephi，Bosch，Sony等大廠冗余的傳感器，對下與Bosch ESP EPB EPS等全家桶緊密結合，加之Baidu，四維圖新等廠的高精度地圖信息加持， 基本可滿足全部Level2的功能需求與部分Level3的功能需求。對于系統ASIL D的設計來說，冗余是一種途徑，Safe Stop則是最終的結果。對于冗余的解釋為：域控制器內部冗余和除Lidar外的傳感器均采用傳感器及其通訊冗余策略以達到ASIL B的標準，即多傳感器多路通訊；對于Safe Stop的解釋為：對于任何一種系統失效(硬件、軟件)的發生，系統都可以完成對駕駛員的警示和路權交接或安全停車以保證駕駛員的安全。

軟件方面：

在軟件架構方面，對于標準軟件：Vector的PREEvision、VectorCAST等大禮包負責Classical AUTOSAR BSW中RTE、RTOS、Mem、ECU Abstraction、Diag、Communication Protocal等下層服務，Mathwork的大禮包用于應用層服務，BSP則由芯片廠商提供。這種約定俗成的定制方案可以解決大部分MISRA需求，但對于神經網絡的存在目前并無低成本的、可靠的、復用性強的方案出現。這部分黑盒的存在引入了SOTIF的概念并導致了Validation策略和框架對比傳統ECU的變化。

這里馬克一下RTE和SOTIF，目前絕大多數廠商的Demo都是基于ROS的框架搭配Unix系統實現，個人的理解為缺點是不能量產、安全等級低，優點是低硬件依賴度、更適應快速迭代開發的過程。SOTIF目前還未推出正式版本，在當前版本的SOTIF中，系統需求，場景分析和測試都被重點提及，測試方面會后續說明。

硬件方面：

對于域控制器的硬件方案來說，ASIL D是必備的，目前各家半導體廠商均給出了自家的拳頭產品，其中較為出色的就是Nvidia的Drive PX、Pegasus系列，Renesas的R-Car系列，NXP的Blue Box系列。對于硬件來說“概念林志玲，量產羅玉鳳”的情況不大可能出現，而且域控制器中并不一定所有的SoC都需要ASIL D，在SoC的選擇上ASIL D的SoC通常用于執行機構的控制和診斷，其他QM、ASIL A、ASIL B的SoC則負責感知和計算，SoC間互相監控冗余，也可以做到ASIL D的效果。在實際項目中往往其最大的風險來自于量產的時間。

在這種高冗余的設計模式下，自動駕駛系統可以完成理論上ASIL D的實現。但ASIL D并不代表絕對的安全，功能安全是一種藝術。在自動駕駛系統開發的過程中，被所有人質疑的神經網絡模型將使用新的Validation策略和框架予以驗證。

個人認為Validation是在自動駕駛量產過程中非常大的難題，對于如此特殊的系統來說，好的軟件開發決定了基礎，而好的驗證則決定了客戶及市場的滿意度。

Validation方面:

自動駕駛的驗證在內容上不再局限于單元測試，集成測試，軟件測試，系統測試，系統集成測試，整車測試等幾塊V Cycle的定義。由于在SOTIF中Simulation Scenario的提出，Validation被賦予了更重要的意義，對于黑盒系統，新形式系統測試和整車測試不但可以增加產品置信度，更可以加速產品迭代效率，增加黑盒可靠性。一般來說系統測試及之后的測試內容會分為三塊，功能測試，系統測試，和整車測試，對于三塊不同的測試內容，ASPICE中對于測試覆蓋度和測試深度對于同的安全目標有著詳細的定義，ISO26262中也針對不同的安全等級做出了不同的推薦。最后，各大歐洲主機廠的量產方案大多以“脫離比例”為Software Release指標，這點在各大Safety Report上也可見一斑。

三、個人感想

自動駕駛的系統設計最終很可能偏離傳統的汽車電子路線，Adaptive AUTOSAR和SOTIF等新標準的出現證明了這一點，但無論如何，ISO26262的意義不僅針對最終的產品，更存在于每個汽車電子工程師點滴的產品開發生涯中，產品手中過，安全心中留。