2萬字長文說清自動駕駛功能架構的演進

目錄

前言

一、架構的藝術

（一）關于架構的基本概念

（二）基于場景服務的“功能驅(qū)動”

二、ADAS功能架構的演進

（一）分布式ADAS架構

（二）域控式ADAS架構

（三）跨域式ADAS架構（行泊一體）

（四）跨域冗余式ADS架構（L3和L4的標配？）

（五）中央計算平臺（行泊艙一體）

三、架構演進的總結(jié)

架構引發(fā)的產(chǎn)業(yè)鏈重塑

批判與尊重

本文參考資料

為什么？

為什么同樣實現(xiàn)NOA功能，特斯拉只用攝像頭方案，而大部分OEM還會增加毫米波雷達，甚至激光雷達？

為什么5R1V架構這么受歡迎？到底有什么經(jīng)典之處，這種架構會長期存在嗎？

為什么L3級以上自動駕駛功能一定要用冗余技術？是否可以不用？

L4架構相比L3做了哪些升級？

域控制器為什么通常采用SOC+MCU架構方案？

行泊一體域控制器是是過渡，還是終極形態(tài)？

中央計算平臺會是ADS乃至整車的終極架構形態(tài)嗎？

自動駕駛的安全如何設計，如果規(guī)避SOC陷阱？

國內(nèi)的自動駕駛能力真實現(xiàn)狀到底啥樣？

造車新勢力們“短平快”開發(fā)策略會不會有后遺癥？

以上問題都會在本文中找到答案，相信通過本文的閱讀，大家會對自動駕駛有更深層次的認知。

所有的技術方案、架構形態(tài)只是實現(xiàn)需求的一種技術路線！

想必大家都曾思索過以上問題，筆者以第一性原理，談一談智能駕駛到自動駕駛的技術發(fā)展路線，同時剖析國內(nèi)幾家OEM、造車新勢力的自動駕駛現(xiàn)狀。

先有需求、后有設計是正向開發(fā)的第一理念，這個理念放在智能駕駛上一樣適用，無論用了多少傳感器，什么芯片，多少算力，幾大冗余技術等等，這些奪人眼球的配置都只是表象——并不是因為車上的硬件配置多牛逼、軟件迭代多快速才能實現(xiàn)自動駕駛，而是為了實現(xiàn)自動駕駛XX功能才選擇了這種方案。

本文以電子電氣架構的理念和視角分析并預測行業(yè)主流ADAS架構到ADS架構的演變，不同架構的技術實現(xiàn)方案及優(yōu)缺點，同時結(jié)合國內(nèi)主流OEM、新勢力的自動駕駛現(xiàn)狀并分析其自動駕駛路線及產(chǎn)品競爭力。

一、架構的藝術

（一）關于架構的基本概念

本文貫穿了自動駕駛功能架構、系統(tǒng)架構，網(wǎng)絡架構，那么有必要先和大家統(tǒng)一架構的概念和認知。

你也說架構、我也說架構，仿佛不談幾句架構就跟不上時代了，近兩年新老OEM在新車發(fā)布會、智能駕駛產(chǎn)品發(fā)布會，不談幾句架構，那都彰顯不出產(chǎn)品高端，體現(xiàn)不出我們技術底蘊，寫PPT的也是受累了，筆者希望從一個正確的、完整的視角闡述架構的來源和意義，看它在OEM和Tier1的產(chǎn)品開發(fā)中到底起到什么作用！

“架構”這個概念最早是德爾福提出的，由博世把它的迭代路線可視化了，近兩年“軟件定義汽車”的概念把EEA這個概念再次炒火，同時特斯拉先進的EEA工程落地，屬實讓底蘊深厚的OEM羨慕嫉妒，但是僅看博世的架構路線路圖和特斯拉的高內(nèi)聚架構，反而把架構說小了，把架構核心作用和意義忽視了，下面我們自頂向下看看架構的范圍：

物理（電氣）架構：

上圖是整車電器件布置和線束二維布置，看起來線束和電器件密密麻麻布置在二維圖上，通常在OEM叫物理架構，有的公司也叫電氣架構或者整車電氣拓撲。核心是體現(xiàn)整車電子電氣的布置關系和連接關系，主要工作是電氣原理圖設計、電源分配設計、搭鐵分配設計、二維線束走向與三維布置設計。

在分布式開發(fā)的時代，ECU特別多，大概2018年之前，各家OEM為了達到電器件布置和線束走向優(yōu)，通常購買同行暢銷車型，拆解對標。物理架構設計對整車NVH表現(xiàn)、線束成本、車間安裝，售后維修有很大的影響 ，限于篇幅不再繼續(xù)解析。

功能架構：

本文的“分布式架構”、“域控式架構”等都是整車功能層級的架構，體現(xiàn)了功能實現(xiàn)所需要的完整的電器要素和邏輯關系（傳感器-控制器-執(zhí)行器），主要工作輸出物是功能定義規(guī)范以及故障后處理策略，這里的架構雖然是一個個硬件實體，但不能體現(xiàn)出物理布置關系，也有公司把它稱為邏輯架構。

系統(tǒng)架構：

系統(tǒng)架構和功能架構的區(qū)別在于架構的層級不一樣，系統(tǒng)架構是ECU層級的，體現(xiàn)了ECU內(nèi)部的元器件邏輯關系，系統(tǒng)架構是最具爭議的一個詞，在不同場合、不同語境代表的含義也不同，比如本文的各個ADAS功能架構圖，也可能被稱為系統(tǒng)架構，由于“系統(tǒng)”二字范圍可大可小，結(jié)合語境，雙方能會意即可。

網(wǎng)絡架構（網(wǎng)絡拓撲）：

（圖片來源：知乎作者：冷酷的冬瓜）

上圖大家應該不陌生，是特斯拉M3的網(wǎng)絡拓撲，好多人誤認為它就是特斯拉的電子電氣架構，實際上網(wǎng)絡拓撲主要體現(xiàn)各個ECU在哪個網(wǎng)段、在總線上連接關系，比如常規(guī)的動力PT-CAN、車身BD-CAN、駕駛輔助AD-CAN，不同網(wǎng)段的總線類型可能不同（LIN/CAN/CAN-FD/以太網(wǎng)），帶寬和速率也不同，個別ECU之間如果僅僅是私有信息，還會有私有CAN（只是兩個ECU之間信息交互）。

不論是物理架構、功能架構、系統(tǒng)架構還是網(wǎng)絡架構都是EEA的一部分，它們分別體現(xiàn)了EEA不同維度的信息，所以一個先進的EEA必須要綜合考慮架構的各個維度；架構是虛虛實實的存在，它從高維度上抽象地定義了各電子器件之間的邏輯關系，定義上層規(guī)則，從低緯度上又依賴于各個器件做工程實現(xiàn)和維護各電子器件規(guī)則，從這個層面講架構設計就是設計架構！

全文從分布式架構→域控式→跨域式→跨域冗余式→中央式，講解每一代架構的內(nèi)在關聯(lián)，讓大家切身體會架構的藝術！

（二）基于場景服務的“功能驅(qū)動”

自動駕駛的技術路線和架構形態(tài)都是結(jié)果，而不是原因。

談到這里，我聯(lián)想到去年年底，我的一位大學同學找我?guī)兔?，?nèi)推一臺我司車輛，當我問到要哪款車、以及什么配置的時候，顯然我同學是個地地道道的外行，他說“高速上能自動跟車，能自動拐彎，變道的時候有危險能報警那個”，然后，我以工程師的角度得出結(jié)論，他想要的功能是自適應巡航ACC+車道保持LCK+變道輔助LCA，最終我給他選擇了對應配置的車輛。

言歸正傳，歸根結(jié)底終端消費者關注的是在什么場景下，車輛具備什么服務，能輔助、代替駕駛員更舒適、更安全地操控車輛，企業(yè)將消費者對場景的需求抽象為服務（service）、具化成功能（function）、轉(zhuǎn)化成特征（feature）、細化成工程架構設計(design)，評估傳感器性能，用幾個、控制器的內(nèi)存和帶寬得多大、用什么總線通訊，用什么軟件架構方案，細化為功能需求（requirement），然后選擇供應商進行需求（requirement）實現(xiàn)。

談到這里，想必大家腦海里已經(jīng)出現(xiàn)了共鳴，這就是所謂的基于“功能驅(qū)動”，是EEA的第一理念，沒錯！而行業(yè)內(nèi)對于不同場景的ADAS需求已經(jīng)成為共識，形成了ADAS功能庫，功能有了，下一步就是如何規(guī)劃ADAS架構來實現(xiàn)功能。

行業(yè)內(nèi)自動駕駛功能庫：

值得注意的一點，緊急介入的ADAS功能根據(jù)SAE J3016的規(guī)定被定義為L0，國標也是如此，如：AEB、FCTB、RCTB都屬于L0，筆者只是單純地還原正確的概念，本質(zhì)上，某個ADAS功能屬于L幾意義并不大，只要說清功能在什么場景下會有什么服務，是否需要駕駛員介入就足夠了。

詳細每個功能的描述見九章智駕往期文章《詳解智能駕駛的功能與場景體系》

二．ADAS功能架構的演進

基于功能的升級，需求的增加，自動駕駛架構也不斷進化，筆者結(jié)合博世EEA發(fā)展路線圖并結(jié)合工程實踐繪制了ADAS的架構演進路線：

全文以自動駕駛架構為主線，穿插每一代架構的意義和難點，做最全面的解析！請各位看客老爺耐心閱讀并加以思考，尤其思考每一代架構圖的變化點和背后的含義。

（一）分布式ADAS架構

功能架構簡介：

該架構最高支持到L2級ADAS功能，這里解釋一下，所謂實現(xiàn)的L2需要同時開啟ACC和LCK的開關，這種分布式架構還不能實現(xiàn)一鍵激活L2，行車域無域控制器，泊車域設置控制器。

在該架構下，橫向ADAS功能由集成了EQ4芯片的camera實現(xiàn)，縱向ADAS功能由前毫米波雷達實現(xiàn)，角雷達實現(xiàn)FCTA/B、RCTA/B及DOW/BSD等報警功能，環(huán)視攝像頭和超聲波雷達服務于泊車功能，此架構各個傳感器耦合度極低，各司其職，是典型的分布式開發(fā)，因此對于行車功能也叫1R1V架構，在此基礎上可以演變出4R1V架構（取消前毫米波雷達），此種架構十分依賴供應商，OEM在掌控力方面基本沒有話語權。

泊車采用的，其實也算不上域控制器，而是單獨的一個ECU盒子。因為泊車用的傳感器，超聲波雷達和廣角攝像頭，就是純傳感器里面沒有集成控制器。

簡而言之，在分布式階段，規(guī)控也是由傳感器中的控制模塊負責，而泊車功能的規(guī)控算法則在控制器里。

功能和傳感器的映射關系如下：

架構特點：ECU分散，軟件分散

傳感器配置：行車—5R1V，EQ4集成在camera中；泊車—4環(huán)視+12超聲波雷達

應用車企：吉利、長城、比亞迪、長安、廣汽、北汽、蔚來、理想

評價一個EEA通?？紤]10個維度（評價方法常使用蜘蛛網(wǎng)、普氏分析法，由于不是本文重點，就不再贅述）

十個維度	定義
可靠性	系統(tǒng)在各種場景下保證滿足設計意圖的能力
成本	設計、開發(fā)、制造、驗證、物流、維修各階段的成本
開發(fā)周期	從設計到產(chǎn)品量產(chǎn)的開發(fā)速度
功耗	系統(tǒng)運行能耗
安全性	功能安全、網(wǎng)絡安全的能力
復用性	可移植能力、平臺化設計能力
可拓展性、靈活性	硬件資源的預留、現(xiàn)有硬件的剪裁
兼容性	架構設計與當前工具鏈、接口定義、供應鏈的兼容性
復雜性	架構設計的復雜度
布置靈活性	硬件資源的布置自由度

 

下面，從上述評估EEA的幾個維度評價分布式ADAS架構：

復雜度：集成難度低，開發(fā)周期短，可移植性強，對于OEM而言，主要工作在于集成和標定，大部分ADAS的集成和標定都相對容易，復雜度主要在于AEB標定。

多解釋一下，AEB看似是L0級功能，但是其開發(fā)難度不低于NOA脫手功能，主要挑戰(zhàn)在于如何權衡誤制動和漏制動。這既是功能話題，又是安全話題，業(yè)界做的最好的Mobileye，AEB的成績是10萬公里誤制動一次，俗稱AEB false positive，而這個成績對于預期功能安全的AEB接受準則（某公司要求30萬公里誤制動一次），還遠遠不夠，當前乘用車+商用車的AEB前裝量接近100%，市場配置AEB車輛的數(shù)量巨大，意味著每天都會發(fā)生由于AEB導致的急剎車，進而可能導致追尾事故。

復用性：此架構雖然無域控制器，但得益于SOC的發(fā)展，前攝像頭可集成EQ4/5，作為“域控制器”使用，并統(tǒng)一輸出接口；且縱向L1功能和橫向L1功能接口由camera統(tǒng)一輸出對整車的控制接口，整體功能上實現(xiàn)L2的效果，對于轉(zhuǎn)向、制動、動力的接口無影響，利于OEM平臺化設計。因此，這種操作深得OEM的喜愛。

靈活性：可剪裁掉前毫米波雷達，形成4R1V架構，集成EQ4/5的前攝像頭實現(xiàn)橫縱向ADAS行車功能，但需要EQ4/5開放更多的服務，要加錢！一般單攝像頭價格漲幅＜前毫米波雷達單價。

與此同時，架構做減法，可能導致某些ADAS功能魯棒性降低，如AEB改為攝像頭實現(xiàn)，會由于攝像頭的性能局限導致頻繁誤制動和漏制動，因此對于攝像頭標定和AEB計算車距、目標識別算法有很高的要求。算法做得不好，造成的后果有2個，要么頻繁誤制動（如某著名車企，單攝像頭方案的AEB），要么會漏制動。這種無域控制器的架構形態(tài)，必然會犧牲一部分功能可用性。

兼容性：分布式ADAS架構，OEM很容易被巨頭Tier1綁架——Tier 1們捆綁銷售執(zhí)行器（EPS、ESP），然后找一堆所謂客觀的理由，如果OEM選擇其他公司的執(zhí)行器，那么我們的產(chǎn)品需要同步更改哪里哪里，開發(fā)周期多久多久，開發(fā)費用多少萬…

 安全性：

功能安全：該架構支持的功能清單中，如AEB存在ASL D的安全目標，但是通過執(zhí)行器的性能限制/安全閥值約束，降低整車風險至ASIL B，分配給傳感器整體滿足ASIL B即可，camera和前毫米波雷達滿足ASIL B。

小結(jié)：傳統(tǒng)OEM將同一車型分為3~4個配置，如：低配、中配、高配，頂配，其中低配是為了拉低車型起步價，實際上并不生產(chǎn)；主銷配置是中、高配，隨著ADAS滲透率的提升，以前只有頂配才有的L2級功能，現(xiàn)在中、高配就會配備，同時受限于域控制器價格原因，分布式ADAS架構將持續(xù)存在。

（二）域控式ADAS架構

介紹域控式ADAS架構前，有必要先科普一下多傳感器融合算法，因為域控式ADAS架構是OEM和Tier1對于感知算法的第一次博弈，OEM逐漸蠶食Tier1的“算法專利” ，各位看客老爺請細看OEM如何逐漸摘掉“組裝廠”的帽子。

為啥要多傳感器融合？

多傳感器融合的核心目的是提高系統(tǒng)決策、規(guī)劃的正確性，為了實現(xiàn)這個目標，傳感器必須從基礎的感知能力進化到深層次的認知能力，通俗地解釋一下，類比人類，我們認識世界是通過視覺、觸覺、嗅覺獲得外界的多維度信息由大腦統(tǒng)一加工處理，從而來認識世界，多傳感器融合的底層理念就源于這里。

多傳感器融合算法有哪幾種？

多傳感器根據(jù)信息不同層級的融合從宏觀上分為數(shù)據(jù)級融合和特征級融合，這里不長篇大論理論層面的東西，著重說一下融合算法。

各傳感器輸出的信息都存在不確定性，針對不確定信息進行融合實際上是一個不確定性推理的過程，融合算法基于大量傳感器的輸出信息通過不斷訓練，更新各個傳感器權值，得到黑盒推理機制，利用神經(jīng)網(wǎng)絡的信號處理能力和自動推理功能，不斷優(yōu)化、迭代算法，行業(yè)內(nèi)把感知融合算法分為后融合和前融合算法。

① 后融合算法，見下圖：

每個傳感器獨立輸出原始數(shù)據(jù)然后對每個傳感器的數(shù)據(jù)進行處理，輸出識別結(jié)果，最后在域控制器內(nèi)設計合適的傳感器權重做最終的仲裁。可以簡單的理解為這種感知融合方式類似投票機制，每個傳感器有不同的話語權。

先用最通俗的例子說后融合算法：員工相當于傳感器，領導是感知融合算法，每個員工都有發(fā)言權，但是每個人的權重不一樣，領導最終會把兩個人說的話進行加權，輸出決策結(jié)果。

這種算法的優(yōu)勢在于邏輯簡單，計算速度快，通訊帶寬小，劣勢在于信息損失大，信息精度低。雖然說后融合算法簡單，但是目前大部分OEM僅僅能處理毫米波雷達的融合，視覺算法的融合還是依賴芯片+算法系統(tǒng)供應商（Mobileye和地平線這種）。

② 前融合算法，見下圖：

前融合算法指的是在傳感器原始數(shù)據(jù)層面進行融合，原始數(shù)據(jù)保留了最全的目標信息，融合算法根據(jù)各個傳感器輸出目標的紋理特征、三維信息、RGB信息綜合判斷，然后輸出一個準確率更高的結(jié)果。在一些場景下，如果使用后融合算法，由于每個傳感器只能探測到目標的一部分，而這一部分由于信息不全，很容易被作為噪點過濾掉，但是前融合算法就可以規(guī)避這個問題，前融合雖好，但是對處理器要求很高，需要高算力、高帶寬的通訊，同時非常依賴大量數(shù)據(jù)的驅(qū)動以及數(shù)據(jù)閉環(huán)來優(yōu)化算法。

通俗解釋：還是用上面的比喻，這個領導（前融合算法）不會輕易相信某一個員工或者某幾個員工的話，領導要求每個員工都把他們看到的、聽到的原始信息提交上來，領導會根據(jù)每個人的特點，綜合評估，輸出最終結(jié)果，對于領導而言很費腦力。

目前具備前融合算法能力的OEM不存在，好一點的科技公司能做到把毫米波雷達+攝像頭信息做融合，但是對激光雷達的點云處理能力目前還是捉襟見肘，本人認為未來能把前融合算法做好的前提是強大的AI團隊+對各種傳感器性能有深入了解，缺一不可。

  

回到本章節(jié)正文：

功能架構簡介：

域控式架構最高支持到ADAS功能清單內(nèi)L2級別功能。

硬件上，相比于分布式ADAS架構，域控式架構僅僅增加了域控制器，那么域控制器會帶來什么收益呢？筆者基于開發(fā)經(jīng)驗總結(jié)以下三點：

優(yōu)勢1：域控式ADAS架構將sensor控制算法上移，從傳感器端上移到域控制器端，域控制器做簡單的后融合算法，提高了功能可用性；

優(yōu)勢2：域控式ADAS架構引起HMI設計變化，開關可以“一鍵多用”，如撥一次激活ACC功能，撥二次激活TJA功能，不必用戶從HUT軟開關上再次開啟LCK功能；

優(yōu)勢3：此架構最大的意義在于OEM逐漸打破了Tier1的封鎖，應用層算法被OEM掌握在手里了，把對Tier1傳感器的依賴轉(zhuǎn)移到對域控制器芯片的依賴，OEM的自由度會高一些，畢竟芯片的可選擇性會多一些。

架構的核心之一在于功能分配、資源合理利用，域控式ADAS架構功能分配如下：

紅色√是相比于分布式ADAS架構下，傳感器功能的拓展。比如AEB、FCW功能調(diào)用了前角雷達信息，前角雷達和前毫米波雷達/攝像頭的FOV覆蓋區(qū)域重疊設計，形成異構冗余，那么對于一個功能而言，更多的傳感器覆蓋，通常漏檢率會降低。

但并非絕對如此，感知融合算法的誤檢率和漏檢率跟每個傳感器的權重也有關，下面插播一段，剖析特斯拉AEB漏制動的感知融合算法。

特斯拉為啥刪掉毫米波雷達？

網(wǎng)絡上有很多對特斯拉事故的分析，筆者不進行解析，本文從算法角度闡述，用數(shù)據(jù)清晰地展示給讀者，相信讀完后大家會得到答案。

已知AEB為毫米波雷達+攝像頭融合方案，算法方案為后融合，筆者做了一個簡易的AEB事件仿真，融合算法模型：當毫米波*A+攝像頭*B≥80%，則激活AEB。結(jié)果如下——

選取幾個典型事件進行分析：

AEB事件1：這個案例告訴我們，如果權值比較低的毫米波在某緊急場景下探測率低（50%），將會導致1+1＜1的后果，還不如刪除毫米波雷達，一句話：臭魚攪得滿鍋腥！

AEB事件3：權值高的傳感器如果達不到及格線（80%，因為感知融合算法模型是超過80%才激活，那么，如果只有一類傳感器，其檢測正確率也不能低于80%，否則就會出現(xiàn)短板效應），那么AEB也無法激活，好比一個在其位不謀其職的領導，權力很大，能力很差，那么結(jié)局可想而知！

AEB事件5&7：這個案例告訴我們，雖然毫米波雷達探測力很強（85%），奈何隊友不給力，導致整體1+1＜1的結(jié)果，也無法激活AEB。

AEB事件6：這個案例告訴我們即使兩個話語權一樣的人，但是如果一方達不到及格線，那這個隊友就很難帶了。

綜上所述，數(shù)據(jù)顯示沒有毫米波雷達，9次AEB事件中會發(fā)生3次漏制動（表格第5列，小于80%的數(shù)據(jù)個數(shù)），而增加毫米波雷達，發(fā)生了7次漏制動（表格第6列，小于80%的數(shù)據(jù)個數(shù)），盡管此表格僅為部分數(shù)據(jù)，但是我想大部分讀者已經(jīng)理解為什么特斯拉不再用毫米波雷達了吧？

多傳感器異構融合方案，如果采用后融合算法，對權值的設定非常考驗算法的設計，需要大量的仿真及實車標定數(shù)據(jù)支撐，否則容易引起1+1＜1的情況。另一方面，多傳感器后融合一定是強強聯(lián)合，每個傳感器的能力不能太差；可能有的朋友會說多傳感器融合，未必是強強聯(lián)合，也可以是取長補短，沒錯！下文會提到前融合算法。

另外，現(xiàn)階段3D毫米波雷達雖然是號稱全天候傳感器，但是由于其分辨率低，通常漏檢率會高一些，但是又因為其對金屬物體敏感，遇到金屬會頻繁誤報，在開發(fā)中實在有一種“食之無味，棄之可惜”的尷尬。

那么是否毫米波雷達就真的很雞肋呢？答案肯定不是，在AEB這個案例中，用到毫末波雷達的目標探測屬性，這不是它的強項，但如果用毫米波雷達的目標速度/距離信息作為前融合算法的輸入，那效果還是要優(yōu)于攝像頭，一句話：取其長，避其短！

域控式ADAS架構存在的意義是什么？

上文已經(jīng)提到，本質(zhì)上域控式ADAS架構是算法的上移，關鍵點在于后融合算法的設計和芯片選型，芯片的選型相對自由一些，大部分OEM采用Mobileye EQ4+英飛凌TC39x系列的組合，由于短期內(nèi)大部分OEM對視覺算法處理還無法趕上Mobileye，考慮Mobileye對算法的封閉，一些OEM已經(jīng)和開放度更高的地平線合作，參與視覺算法的研發(fā)，這個階段的OEM已經(jīng)不是簡單的組裝廠了！

主流域控制器設計方案：

方案	芯片組合	資源分配	代表企業(yè)
方案1	EQ4+ TC297	EQ4被從攝像頭中抽取出來，集成到域控制器中，提高攝像頭模組的可選性。 MCU作為毫米波雷達的融合芯片，同時作為安全島以及整車底盤的接口。	長城汽車
方案2	2*J3+TC397/RH850	2顆地平線J3芯片負責跑感知融合算法+規(guī)控算法	理想汽車

域控式ADAS架構評價：

成本：域控式ADAS架構形態(tài)從成本上要高于分布式ADAS架構，雖然支持的功能可靠性、魯棒性有所提高，但是收益和代價仍不成正比；

可拓展性、靈活性：此架構類型是算法上移，域控制器單MCU，視覺依賴單SOC（這顆soc只是位置從攝像頭中轉(zhuǎn)移到了域控制器中，但處理的數(shù)據(jù)仍然只限于攝像頭數(shù)據(jù)，可以理解為“工位調(diào)整了，但工作內(nèi)容沒變”），功能上可拓展性差、拓展難度大；

兼容性：域控制器和底盤控制器接口進行平臺化設計，當自動駕駛架構演進為跨域冗余式架構，此域控制器可以作為冗余控制器存在，從L3功能降級為L2功能運行，或者執(zhí)行MRM本車道停車。

安全性：L2功能雖然有ASIL D的安全目標，但是可以在執(zhí)行器（轉(zhuǎn)向系統(tǒng)、制動系統(tǒng)）做安全約束，降低域控制器的功能安全等級

小結(jié)：單從成本和可拓展性兩個維度就注定域控式ADAS架構的生命周期不會太長，但考慮長遠戰(zhàn)略，OEM又不得不研發(fā)這類架構，畢竟這是域控制器自研的第一步，是OEM掌握話語權的開始。

這種架構形態(tài)對于OEM而言是一種技術過渡的中間態(tài)，然而這個階段卻是OEM技術沉淀的一個緩沖期， OEM同步搭建感知融合團隊、域控制器團隊、規(guī)控團隊、基礎軟件團隊、標定團隊、定位團隊、軟硬件集成團隊，大大提高了資源整合能力（控制器布置、線束布置、總線通訊設計、接口定義平臺化設計、工具鏈的打通、仿真測試能力建立）， 時機成熟后OEM會迅速切入跨域式融合架構，把域控式架構中的控制器從架構中剝離出來，作為后續(xù)跨域冗余架構的fallback控制器（別急，下文跨域冗余式架構章節(jié)會詳細解析），這就體現(xiàn)了架構的藝術，架構的價值！

（三）跨域式ADAS架構（行泊一體）

低配版行泊一體功能架構圖

功能架構介紹：

這代架構相比上一代架構從硬件形態(tài)上增加了GNSS+IMU組合定位，從軟件包上加入ADAS地圖，行車域+泊車域控制器融合成行泊一體域控制器。

支持功能：功能清單中L2及以下所有ADAS功能

局限性：ADAS地圖無法支持車道級定位，無法安全通過匝道，無法實現(xiàn)點到點的行車

安全性：側(cè)后方無視覺傳感器，側(cè)后方只有角雷達，主動變道有風險

高配版行泊一體功能架構圖

變化點：相比低配版，高配版所使用的地圖由ADAS地圖升級為高精地圖，高精地圖硬件盒子一般集成到域控制器內(nèi)，車身兩側(cè)分別增加2個側(cè)視攝像頭，和對應側(cè)的角雷達形成異構冗余

優(yōu)勢：

1. 支持高速公路自動上下匝道場景，實現(xiàn)點到點的NOA功能；

2. 冗余側(cè)視攝像頭的數(shù)據(jù)引入降低了目標漏檢率，降低主動變道的風險；

開發(fā)難點：側(cè)視攝像頭算法開發(fā)，側(cè)視和角雷達后融合算法的設計和測試

系統(tǒng)架構如何設計？

上文提到電子電氣架構開發(fā)是自頂向下的開發(fā)，系統(tǒng)架構的設計道理也一樣。

正向開發(fā)的思路：系統(tǒng)功能清單→功能分配到抽象的邏輯模塊→硬件架構設計→功能分配到硬件→應用層軟件開發(fā)，目前能力靠前的OEM不斷擴大軟件的投入，一方面招兵買馬挖墻腳，一方面提高校招的門檻，已初步具備應用層軟件開發(fā)能力。

為啥域控制器通常采用SOC+MCU架構方案？

首先，域控制器不一定是SOC+MCU方案，單SOC也可以，比如使用單TDAV4芯片，只要SOC的能力可以覆蓋MCU的一些特性，從實現(xiàn)功能角度單SOC也沒問題。

主流方案是域控制器使用SOC+MCU方案，因為SOC往往是基于GPU/TPU架構，比如華為自研的達芬奇架構，這類芯片擅長做大規(guī)模低精度的浮點型運行，作為感知主處理芯片（處理前視、側(cè)視、環(huán)視攝像頭、高精地圖信息），而MCU處理毫米波信息、超聲波雷達信息，同時MCU作為和整車底盤CAN通訊接口；此外，緊急工況下，MCU可以靠毫米波雷達實現(xiàn)AEB功能。

另一方面，MCU可以作為安全島來實現(xiàn)最低風險策略，如SOC出現(xiàn)故障，持續(xù)輸出過大的轉(zhuǎn)向指令，MCU設計固定的安全閾值，比如當轉(zhuǎn)向扭矩大于3牛米時，MCU不響應請求，來降低整車風險，從而實現(xiàn)功能安全，由于MCU相比SOC邏輯簡單，內(nèi)置的自檢（BIST）檢測本身的故障，錯誤檢查和校正（ECC）機制可檢測并校正影響內(nèi)存（如閃存）和內(nèi)部總線的數(shù)據(jù)誤差，以及使用多核鎖步很容易實現(xiàn)功能安全ASIL D的要求，如OEM最常用的TC397芯片，這里糾正一個容易混淆的概念，MCU雖然可以作為安全島來診斷SOC的故障，但是并不意味著SOC所有的失效都能被MCU探測到。 

得益于SOC的發(fā)展，類似德州儀器TDAV4H和寒武紀SD5223單SOC都可以實現(xiàn)MCU的屬性， 比如SOC內(nèi)“MCU區(qū)域”，采用多8個R核，4組雙核鎖步設計，同樣可以可以實現(xiàn)處理USS算法和安全島的作用，如圖片右側(cè)：

(圖片源于網(wǎng)絡：TDAV4H芯片架構)

未來單SOC的價格會比SOC+MCU便宜，即使單SOC也能符合功能安全ASIL D的要求（目前行業(yè)內(nèi)的大算力SOC只能做到ASIL B），也可以滿足網(wǎng)絡安全要求，但是對于完全自動駕駛安全而言做到“相對安全”還遠遠不夠，需要做到“本質(zhì)安全”，因此筆者認為外掛MCU還是非常有必要，筆者是獨立MCU的擁護者。

跨域式系統(tǒng)架構設計

行業(yè)存在4種系統(tǒng)設計方案

① 單SOC+MCU，如華為MDC610控制器；

② 雙SOC+MCU，如華為MDC810控制器；

③ 三SOC+MCU，如地平線行泊一體方案；

④ 單SOC，如知行科技IDC3.0方案、寒武紀SD5223行泊一體方案；

上文提到，不論采用哪種方案，萬變不離其宗，不變的是上層功能和系統(tǒng)feature，變化的是系統(tǒng)內(nèi)部的硬件架構，當意識到這點，系統(tǒng)設計就容易理解了。

系統(tǒng)設計流程：三個關鍵詞：分解、轉(zhuǎn)化、分配。

系統(tǒng)架構師分解上層功能，轉(zhuǎn)化成系統(tǒng)feature（大部分公司叫邏輯模塊，屬于軟件模塊的抽象），分配到架構要素（電源模塊、處理芯片等），然后相關工程師設計內(nèi)部通訊、評估是基于AP還是CP進行軟件算法設計。

行泊一體系統(tǒng)feature導出和資源分配：

上層功能	系統(tǒng)feature	特征描述	安全級別	資源分配
行車域	Feature1	前向攝像頭感知數(shù)據(jù)處理	ASIL B	SOC
行車域	Feature2	側(cè)向攝像頭感知數(shù)據(jù)處理	ASIL B	SOC
行車+泊車域	Feature3	環(huán)視感知數(shù)據(jù)處理	ASIL B	SOC
行車+泊車域	Feature4	多攝像頭數(shù)據(jù)融合	ASIL D	SOC
行車域	Feature5	地圖引擎	ASIL B	SOC
行車域	Feature6	毫米波數(shù)據(jù)處理	ASIL B	SOC/MCU
行車+泊車域	Feature7	超聲波數(shù)據(jù)處理	QM	SOC/MCU
行車+泊車域	Feature8	環(huán)境模型	ASIL B	SOC
行車+泊車域	Feature9	定位	ASIL B	SOC
行車域	Feature10	目標軌跡預測模塊	ASIL D	SOC
行車+泊車域	Feature11	規(guī)劃模塊	ASIL D	SOC
行車+泊車域	Feature12	整車控制模塊	ASIL D	SOC/MCU
行車+泊車域	Feature13	故障診斷	ASIL D	SOC/MCU
…	…	…		…

系統(tǒng)設計過程中如何分解功能，如何轉(zhuǎn)化成系統(tǒng)feature很好理解，如何分配資源是開發(fā)難點，筆者總結(jié)如下兩點經(jīng)驗：

分區(qū)設計：正向開發(fā)先定義架構，評估所有feature所需要的硬件資源總和，后進行芯片選型，不同feature分配到不同芯片（如果是單SOC則分配到不同核）；同時由于不同feature的安全等級不一樣，需要進行分區(qū)設計，如：低ASIL的feature不可以訪問(寫) 高ASIL的內(nèi)存分區(qū)，避免產(chǎn)生串擾。

分時設計：行車、泊車功能不同時起作用，那么為了節(jié)省資源，可以共享硬件資源，做分時管理，通常由MCU做狀態(tài)機管理，單SOC方案則由SOC實現(xiàn)。

設計難點

在設計行車和泊車獨立域控制器的時候，行車功能很難調(diào)用環(huán)視攝像頭的信息和超聲波雷達信息，而行泊一體控制器使用前融合算法則可以規(guī)避此問題，比如NOA功能調(diào)用魚眼攝像頭的數(shù)據(jù)來檢測一些場景來從而避免碰撞，據(jù)悉知行科技和毫末智行都使用該方案，如下圖：

（圖片來源：知行科技）

前融合算法的優(yōu)勢是毋庸置疑的，但是能把前融合算法做好，而且能SOP的企業(yè)目前還沒有，行業(yè)內(nèi)看似百花齊放，實則99%企業(yè)都處于demo車階段，大部分OEM/科技公司都是采用后融合，某個功能的特定場景采用前融合策略。這并不是真正意義的前融合算法，在行泊一體的上半場硬件比拼中，大家不分高下，下半場就要拼軟件算法了，尤其是對環(huán)視攝像頭和側(cè)視攝像頭數(shù)據(jù)的融合算法和目標軌跡預測算法。

OEM的“外患、內(nèi)憂”有望解除

在分布式架構和域控式架構時代，Mobileye無疑是最大的贏家，一個EQ4+封閉算法就把OEM拿捏得死死的，集成EQ4的攝像頭也分割了前毫米波雷達的市場份額，行業(yè)恨Mobileye久矣，對于OEM而言這種局面毫無安全感，此乃外患。

上文提到分布式ADAS架構會長期存在，這意味著，在低端ADAS市場上，Mobileye 還會繼續(xù)收割紅利，這種局面OEM一直想打破，隨著地平線等企業(yè)的發(fā)展，Mobileye在低端ADAS市場份額也會收窄，而行泊一體高配置ADAS市場，OEM去“Mobileye化”才剛剛開始。

另外，OEM內(nèi)部的行車、泊車分布式開發(fā)的局面，形成臃腫的開發(fā)團隊，部門內(nèi)領導的權力之爭，也日益彰顯。不同車型、不同平臺、不同供應商產(chǎn)品、不同接口定義致使各個組織割據(jù)分割，往小了說拉幫結(jié)派，影響公司級ADAS平臺化設計，往大了說影響整車EEA的進步和公司的未來，此乃內(nèi)憂，而大公司的組織架構小變革是換湯不換藥，大變革通常是大象轉(zhuǎn)身。

筆者認為行泊一體域控時代的到來對于OEM是自我革新的契機，從組織架構上優(yōu)化團隊，從公司EE架構路線上進行平臺化設計。

（四）跨域冗余式ADS架構（L3和L4的標配？）

L3需要什么形態(tài)的架構？

回歸架構設計流程，場景的需求抽象為服務（service）、具化成功能（function）、轉(zhuǎn)化成特征（feature）、細化成工程架構設計（design），生成工程需求（requirement），然后我們再回顧一下SAE J3016對L3的定義描述：L3系統(tǒng)執(zhí)行ODD內(nèi)全部的動態(tài)駕駛?cè)蝿眨―DT），且目標和事件的探測和響應（OEDR）是系統(tǒng)，說直白些就是駕駛員可以脫腳、脫手、脫眼，映射到文章開頭的ADAS功能清單也就是HWP、UNP，以上是service和function，那么它的特征（feature）如何分析？

先拋一個結(jié)論：L3特征分析是設計的難點，產(chǎn)品的性能局限是落地的難點。

在設計L3系統(tǒng)時，大部分OEM/科技公司都宣傳，用冗余架構啊，傳感器冗余、控制器冗余、執(zhí)行器冗余、通訊冗余、電源冗余，說的像沒說一樣，這種回答毫無工程落地指導意義，工程實現(xiàn)就不用考慮成本嗎？不用考慮三維布置嗎？當問到冗余的必要性，什么場景，什么情況才需要冗余，多數(shù)原因又是“對標”，本文反反復復地說需求是正向地、系統(tǒng)性地導出的，這樣才能保證設計需求的正確性、完整性、追溯性。

筆者從功能的可用性、安全性兩個維度進行特征導出（僅供參考）：

表格起到拋磚引玉的作用，對于L3而言，大部分OEM/科技公司的架構設計幾乎都是源于“對標”，導致L3的硬件架構雖然雷同，但是整車策略、魯棒性、安全性卻天差地別，由于沒有基于正向?qū)С鎏卣鳎╢eature），漏掉了一些特征，導致整個功能需求的合理性、正確性、完整性壓根無法保證，這就是為什么說L3特征分析是設計的難點。

那么產(chǎn)品的性能局限是L3落地的難點如何理解？請耐心往下閱讀。

L3功能架構設計

架構解析：

傳感器采用異構冗余，控制器采用主控+副控設計，副控作為fallback和算力分擔，執(zhí)行器進行全冗余設計，通訊進行冗余設計，預留V2X接口（路側(cè)單元RSU接口）作為路徑規(guī)劃的參考。

主控制器：

L3主控制器通常采用雙SOC+MCU設計，SOC跑感知融合算法+規(guī)控算法，MCU作為安全島并且做整車接口?？梢岳斫鉃閟oc是“干活的”，mcu是項目接口人，它把信息轉(zhuǎn)化成整車認識的格式，通過CAN總線發(fā)給整車。

作用1：處理激光雷達+前視+側(cè)視攝像頭+角雷達+高精地圖數(shù)據(jù)，3種硬件傳感器FOV重疊，做前融合設計，高精地圖作為輔助傳感器，提供車道線+車道級定位信息以及道路分流、合流、限速路段等道路靜態(tài)信息；

作用2：主控制器輸出的控制請求一路通過網(wǎng)關轉(zhuǎn)發(fā)給到執(zhí)行系統(tǒng)，一路通過冗余私有CAN直接發(fā)給執(zhí)行系統(tǒng)，可能讀者會問“直接跳過網(wǎng)關做兩路通訊不就可以嗎”？解釋一下，信息發(fā)到網(wǎng)關公共CAN上，相關零部件都可以收主域控制器的信號做策略判斷；

作用3：輕微故障障管理+故障處理策略的切換，執(zhí)行預設的MRM。如冗余傳感器遮擋/故障，冗余執(zhí)行器故障，主控制器做降級處理策略。

副控制器：

通過上面功能架構圖，你會驚奇地發(fā)現(xiàn)，L3架構的副控制器其實跟行泊一體是一樣的，處理的傳感器也是一樣的。此處的副控制器可以使用上一代行泊一體控制器，這不是巧合，這就是跨域冗余域控制器的使命，也是架構的藝術！每一塊積木都有它的用途，每一代架構都有它存在的意義！

作用1：處理環(huán)視攝像頭+前視攝像頭+前毫米波+超聲波雷達數(shù)據(jù)， 當主控制器無故障時，則將上述目標融合后的信息轉(zhuǎn)發(fā)給主控制器，起到算力分擔的作用；

作用2：實現(xiàn)獨立AEB功能；

作用:3：另外副控制器自身接入這些傳感器也可以實現(xiàn)本車道停車。

當然，只有實力比較強的OEM才能規(guī)劃好這些，沒有架構底蘊的“新勢力”，很難規(guī)劃好每一代架構的遞進關系。

需要特別解釋一下，副控制器跟“冗余控制器”并不是同一個概念。

冗余，意味著互相獨立，在主控故障后，冗余控制器接管車輛。因此，冗余控制器需要跟主控制器完全解耦，只有L4才會采用這種設計理念（L4的副控制器跟冗余控制器是同一個概念）。

但在L3中，副控制器通常承擔算力分擔功能——通俗地說就是，它也參與計算，但只是把計算結(jié)果發(fā)給主控，節(jié)省主控算力。在主控掛掉后，副控制器接管整車，實現(xiàn)L2功能，仍可以保留安全行車的能力；或者，能執(zhí)行MRM就可以。

有些芯片商或者OEM宣傳單芯片、單域控制器能實現(xiàn)L3這類“大言不慚”的話，筆者是嗤之以鼻的，在整車無故障下單芯片、單域控制器完全可以實現(xiàn)L3，那故障后呢？

L3架構的安全考量

“安全”是自動駕駛繞不開的話題，未來國家層面一定會出臺監(jiān)管政策，而且不是簡單地提交一份類似美國“自愿性安全評估報告”就可以，如下圖：

這些報告對于安全的總結(jié)幾乎都是一帶而過，碎片化的信息并不能說明企業(yè)在安全上到底做了什么，大部分企業(yè)都在談遵循ISO 26262&21448&21434流程體系，那么是否真正按流程開發(fā)了？即使按照流程開發(fā)了，產(chǎn)品是否符合了26262并沒有標明啊，不得不說，各家企業(yè)對措辭拿捏得非常到位！

筆者先后從事EE架構、EE安全、自動駕駛功能開發(fā)，坦白地講，僅僅拿最成熟的ISO 26262標準來說，也沒有任何一家OEM敢宣稱其ADS功能涉及的產(chǎn)品完全符合26262要求！

理論物理近百年沒有重大突破，科技達到了技術瓶頸，電子電氣實現(xiàn)“本質(zhì)安全”可能沒希望了，只能做到“相對安全”，ISO 26262&21448&21434本質(zhì)上都是“相對安全”。解釋一下，所謂本質(zhì)安全就是不可能發(fā)生任何危害事件，相對安全是允許發(fā)生危害事件，只要風險足夠低，低到可以被大眾接受就可以。

設計“相對安全”有時要犧牲功能可用性，二者之間如何做權衡？那么安全做到什么程度就可以了呢？如何從策略和系統(tǒng)設計角度來合理規(guī)避風險呢？

安全策略（示例）：

1.當失效發(fā)生在冗余傳感器，功能并不受影響，但是為了避免發(fā)生主鏈路傳感器再次失效的問題，功能上做報警，降級運行，常規(guī)做法是報警降速，駕駛員接管后功能降級到L2。

2.當失效發(fā)生在主控制器，主控自己發(fā)出MRM請求，或者主控和副控的心跳信號丟失（注：周期性握手，表明是否有故障），副控開始依靠前攝像頭+毫米波雷達+環(huán)視攝像頭的前融合策略繼續(xù)運行L2級功能，同時報警，降速。

3.當失效發(fā)生在副控制器，在L3運行過程中，副控上報故障，由主控制器主動報警，告知駕駛員，做降級策略。

4.執(zhí)行器要冗余這個毋庸質(zhì)疑了，因為一旦終端執(zhí)行器故障，功能直接失效。執(zhí)行器做仲裁策略，優(yōu)先執(zhí)行主控制器請求，當主控故障時，才執(zhí)行副控制器請求。

5.主控接入的傳感器和副控接入的傳感器從預期功能安全角度形成互補，對于L3主功能而言是邏輯“或”的關系，這種設計能大幅度規(guī)避corner case，但也不能完全消除corner case。

寶馬汽車安全策略解析：

相比于筆者提到的安全策略，寶馬使用了一種低成本傳感器方案實現(xiàn)MRC（最低風險狀態(tài)）:

（圖片來源：BMW-ADS_20181121_VeCo18_Scalable_Platform_for_AD_FUERST _publish）

圖片最左側(cè)是傳感器輸入，上側(cè)是副控制器，下側(cè)是主控，寶馬的主控接入全集傳感器，副控接入5R1V+DMS。這樣的話，一旦主控失效，副控可以通過5R1V實現(xiàn)fallback，但是靠邊停車存在風險（尤其在車道線模糊的情況下），所以筆者推測寶馬的L3的MRC是本車道停車，對于L3來說沒有問題，對于L4還不夠，具體請繼續(xù)閱讀下文。

行業(yè)SOC大部分只能做到ASIL B，咋辦？如何解決行業(yè)難題？

L3的主控制器毋庸置疑是需要達到ASIL D的（非預期類安全目標），主控制器應該按照ASIL D能力開發(fā)，SOC和MCU是串聯(lián)的關系，那么都要符合ASIL D，ASIL D的MCU常見，但是符合ASIL D標準的SOC還沒有，行業(yè)內(nèi)SOC幾乎都是ASIL B（最新消息：安霸CV2FS/CV22FS芯片已做到ASIL C，獲得Exida認證，為全球首例），那這個差異會造成什么后果呢？

.ASIL B和D在軟件的單元設計和架構設計上差異不大，但硬件方面差異較大——ASIL B的單點、潛伏、隨機硬件失效率的要求均低于ASIL D，意味著只達到ASIL B標準的SOC的某些故障無法被探測到，這導致主域控制器無法設計對應的安全機制，那么如何規(guī)避SOC在功能安全上的短板呢？

安全方案（獨家觀點，僅供參考）：

符合功能安全、預期功能安全的安全架構

預期功能安全考慮：

傳感器分組接入，上文中L3的feature2，考慮到不同傳感器都有性能局限，主控和副控的傳感器從SOTIF角度屬于場景互補關系。

我們都知道，如果主控和副控分別發(fā)出不同的指令，在主控無EE故障的情況下，執(zhí)行器是優(yōu)先信任主控，如果主控沒有EE故障，但主控的輸出結(jié)果卻是錯誤的，這個時候執(zhí)行器就執(zhí)行了一個錯誤的、不安全的指令，產(chǎn)生事故的概率會增大，而上圖這種設計理念恰巧能規(guī)避主路SOTIF問題。

功能安全考慮：

使用副控的毫米波+主控感知融合輸出目標距離做安全距離參考，每路傳感器故障診斷能力要求符合ASIL B，引用Mobileye的責任敏感模型理念（縮寫RSS），來規(guī)避最終的輸出異常。

那么讀者會問，為什么不直接使用激光雷達的目標距離信息呢？

因為激光雷達的數(shù)據(jù)也是靠主控制器SOC處理，如果SOC異常，輸出的距離也是錯誤的。這種架構設計既規(guī)避了SOC的共因失效(硬件失效，ASIL B的硬件度量未覆蓋的那部分失效)，又規(guī)避了主控SOC的AI感知融合算法的錯誤。

對于L3功能架構兩個域控制器必須是冗余關系嗎？

從功能架構圖可以看出，主控制器和副控制器接入的傳感器并不是全集傳感器，而且副控制器接入的傳感器反而更少，意味著兩個控制器不是冗余的關系。L3架構只要能實現(xiàn)最小風險策略，能避免單點失效即可，控制器并不一定需要冗余設計，主控和副控互補設計更利于成本的管控，和硬件資源利用最大化。

電源冗余是必要的嗎？

這個話題行業(yè)內(nèi)爭論較多，90%的工程師都認為冗余電源是有必要的，大部分企業(yè)的L3 demo車輛也試裝了冗余電源，通常采用博世BEG方案，但是冗余電源起作用的概率到底有多大呢？冗余電源起作用的真正原因經(jīng)過分析了嗎？你們的測試數(shù)據(jù)是否顯示冗余電源帶來價值了呢？是由于方案的騎虎難下，還是真有效益？

帶著問題我們先了解所謂的冗余電源是什么，冗余電源包括：供電源頭冗余，供電鏈路冗余。

供電源頭分析：

供電源頭一般是發(fā)電機/DC-DC(電動車)和蓄電池并聯(lián)，從提供電能角度已經(jīng)實現(xiàn)了互補，而且蓄電池容量通常是60-70AH，在發(fā)電機故障下能支持至少15分鐘的運行。這里讀者可能會說EPS的功率通常800多瓦，非常耗電，怎么辦？

實際L3系統(tǒng)執(zhí)行MRM過程中，并不會長時間請求EPS，而且L3并沒有要求必須靠邊停車！到了L4，要么提高蓄電池容量，要么設計備份電池，那就另當別論了，此處我們僅討論L3冗余電源的必要性。

筆者和電源設計工程師溝通得知，如果能消除發(fā)電機/DC-DC和蓄電池的共因失效，那么供電源頭確實可以不需要額外再加一塊小電池。那么，什么條件下，發(fā)電機/DC-D和蓄電池能同時失效呢？

經(jīng)過系統(tǒng)分析，當大于60A的負載發(fā)生短路，導致整車電壓拉低至10V以下，這個電壓無法滿足ADS系統(tǒng)工作時，理論上確實有“共因失效”的可能。那么，實踐中是否可以通過工程的設計來規(guī)避這個共因失效呢？我認為是可以的。

供電鏈路分析：

傳統(tǒng)的供電鏈路的組成是匯流排、繼電器、保險、線束、插件、端子，這里面任何一個環(huán)節(jié)失效都會造成供電異常，那么是否一定要冗余供電鏈路呢？一路鏈路真的無法避免單點失效嗎？或者說，什么情況下才會導致失效，是否可以case by case的解決呢？畢竟線束的成本很高，線束捆變粗，造成布置難度很大。

筆者的看法是從兩方面入手，第一，從整車策略上域控制器接常電（KL30），那么鏈路上就沒有繼電器了，從而可以規(guī)避繼電器的失效；第二，保險絲采用可恢復保險并聯(lián)或者取消保險絲在控制器里做過流監(jiān)控，目前域控制器的電源芯片可以做到，從而規(guī)避保險絲的失效，而匯流排、線束、端子要做好物理防護從而無限接近“本質(zhì)安全”。

以上僅為個人思路，歡迎專家提意見。

OEM當家作主

L3的設計是正向設計的開端，沒有任何一級Tier1或者科技公司比優(yōu)秀的OEM更懂整車，上文提到“L3特征分析是設計的難點，產(chǎn)品的性能局限是落地的難點”，只有OEM從頂層正向的設計才能保證L3特征的正確性、完整性。OEM不斷摸索不同產(chǎn)品性能的邊界，制定合理的、安全的ODD邊界，這是OEM先天優(yōu)勢，在行泊一體架構時，OEM已經(jīng)投入很多資源，提高了自研能力，相信在下一個制高點L3的開發(fā)，基于正向設計的方案才會靠譜！筆者認為L3是OEM當家做主的時代。

L4架構相比L3需要做哪些升級？

L3和L4功能都支持點到點運行能力，L3和L4從功能的正常表現(xiàn)行為實際上無差異，差異點在于功能的異常后的行為，L3要求駕駛員作為fallback用戶，而L4的fallback用戶依舊是系統(tǒng)，意味著L4要具備更強大的fallback能力，相比于L3架構的副控制器就無法滿足fallback要求了，這時我們就要重新根據(jù)L4的功能（function），推導L4的特征（feature），再轉(zhuǎn)化成架構設計(design)。

L4架構方案預測

承接本文L3架構，L4架構相比L3架構最大的變化是副控制器要做真正意義上的冗余，而且兩路必須無共因失效，由于L3架構的副域控制器起到了算力分擔和執(zhí)行MRM的作用，那么：

主控制器設計構想：

L4的主控制器要具備完整的L3能力，也就是L4主控=本文的L3主控+L3副控，基于此構想，L4架構需要開發(fā)L4專屬高性能域控制器，L4主域控制器設計3顆SOC，主域控預留V2X接口，為L4車路協(xié)同預埋硬件。

注：兩顆也可以，比如使用地表最強英偉達orin，性能涵蓋上文SOC#1和SOC#2 feature即可，筆者從可靠性、可用性角度更傾向3*SOC+MCU方案。

冗余控制器設計構想：

從L4的fallback定義出發(fā)，fallback由系統(tǒng)執(zhí)行，在整個駕駛的ODD內(nèi)，不需要駕駛員參與，那么要求即使主控故障，副控制器依舊可以完成ODD內(nèi)全部的動態(tài)駕駛?cè)蝿?，那么思考一下，L3的主控制器是否可以支持呢？是的！這同樣不是巧合，從本文的架構路線進化演進，這體現(xiàn)的是架構的藝術！

L4設計和落地的難點

L3特征分析是設計的難點，產(chǎn)品的性能局限是落地的難點，那么L4呢？

控制器的設計簡單粗暴地說可以增加傳感器接口數(shù)量、提高通訊帶寬、降低時延、堆AI芯片來實現(xiàn)，而L4實現(xiàn)點到點自動駕駛，ODD場景復雜度驟增，傳感器采用怎樣的組合方案？現(xiàn)有的成熟的傳感器技術是否能應對更嚴苛的ODD？是否要使用4D毫米波雷達？是否使用遠紅外相機？

以上感知問題是設計最大的瓶頸，沒有之一，即使是非常牛叉的前融合算法在遇到奇奇怪怪的場景時，對目標的處理能力也捉襟見肘，尤其針對城市車輛和二輪騎行人員的軌跡預測算法，挑戰(zhàn)非常大，出于安全考慮，系統(tǒng)必然會“小心駕駛”。

此時此刻車路協(xié)同派可能要舉手發(fā)聲，仿佛車路協(xié)同這個上帝視角傳感器可以為L4救命稻草，且不說路側(cè)單元（RSU）普及要到何年何月，筆者認同車路協(xié)同對于通勤效率的提升有很大幫助，但是作為傳感器給自動駕駛系統(tǒng)作為決策算法的輸入，這個風險可能比純粹的單車智能風險還要大。

一方面V2X存在網(wǎng)絡安全風險，另一方面RSU也存在性能局限（SOTIF問題），基于二者的考慮，RSU作為傳感器，域控設定RSU權重不會高，筆者認為V2X發(fā)展可能要經(jīng)過3個階段才會參與整車動態(tài)控制，V2X 1.0時代僅是報警功能；2.0時代RSU和高精地圖數(shù)據(jù)耦合，作為全局路徑規(guī)劃算法的輸入?yún)⒖?，提高通勤效率?.0時代才會作為決策算法的參考。

讀到這里大家可能有些審美疲勞，有興許的可以看一下漫威電影《黑豹》片段，這個電影也許預言了V2X的終極形態(tài)：https://www.bilibili.com/video/BV16W411K7XT?spm_id_from=333.337.search-card.all.click

言歸正傳，L4在demo車上拿掉司機、拿掉安全員都沒問題，真正量產(chǎn)做到無人化，L4難度比登月都大，畢竟人類 50多年前就已成功登月。

筆者相繼和小馬智行、滴滴、文遠的同仁了解當前Robotaxi現(xiàn)狀，就目前市場來看，限制場景的L4，如點到點無人巴士、園區(qū)車、港口車、物流車都相繼小規(guī)模落地，但是對乘用車的L4落地大家仍是抱著保守的態(tài)度，原因如下：

其一、人民對乘用車L4的需求也沒有那么強烈—市場需求小

其二、產(chǎn)品的可靠性、安全性并沒有企業(yè)宣講的那么靠譜—技術不成熟

其三、L4乘用車的保險模式也未成熟—相關配套體系不健全

其四、國家監(jiān)管政策也不明朗—國家政策還未跟上步伐

基于上述多方面原因，L4級乘用車的大規(guī)模落地可想而知，短期來看L4的結(jié)局大概率會是限制ODD的高性能L3! 然后美其名曰簡單場景的點到點L4功能，長期來看行業(yè)不會停止對L4的研發(fā)，尤其是主打Robotaxi的企業(yè)還會繼續(xù)“胡說八道地吹”與“腳踏實地地做”。二者缺一不可，不會講故事忽悠（商業(yè)模式）、沒有硬核技術的企業(yè)注定走不遠。

（五）中央計算平臺（行泊艙一體）

什么是中央計算平臺，請參考九章智駕往期文章《EE架構|國內(nèi)主流OEM的中央計算+區(qū)域控制架構信息梳理》

不論是沃爾沃、寶馬還是國內(nèi)的長城、長安、吉利、理想、華為都在規(guī)劃中央計算平臺，大部分中央計算平臺的功能涵蓋了座艙、動力、部分底盤功能，從工程設計角度把行泊艙放一個控制器完全沒問題，從工程實現(xiàn)角度也能實現(xiàn)，本文僅討論中央計算平臺和自動駕駛的關系。

中央計算平臺能支持ADAS嗎？

據(jù)悉長城GEEP4.0架構：中央計算平臺 + 智能駕駛域控 + 智能座艙域控 + 區(qū)域控制吧有望在2022年Q4量產(chǎn)。該中央計算平臺是行業(yè)內(nèi)第一個集成ADAS功能的產(chǎn)品。

其行車最高支持HWA，泊車最高支持APA，其采用的策略是L2配置搭載CCU，L3配置CCU作為小魔盒3.0的fallback控制器，這時CCU的作用和上文筆者所說跨域冗余式架構的副控作用就呼應上了，看來長城在自動駕駛架構迭代和中央計算平臺的發(fā)展路線做出，很好的權衡。

中央計算平臺能支持L3嗎？

目前，在主流的L3架構中，自動駕駛域控制器是主控制器，而看起來更高大上的中央計算平臺則僅扮演冗余的角色——對整車的EE架構來說，中央計算平臺是主角，但對自動駕駛來說，中央計算平臺則是配角。

那么，中央件計算平臺有可能成為L3自動駕駛系統(tǒng)中的主角嗎？

之所以提出這個問題，是因為筆者不看好中央計算平臺（目前，主流廠商所謂規(guī)劃的中央計算平臺，都是單一盒子）在自動駕駛上的前景——對于L3以上ADS，中央計算平臺是配角，不可能是主角，原因有四：

其一、在上文的“L3需要什么形態(tài)的架構”章節(jié)，筆者提出L3不一定需要冗余域控制器，但是要做到主控制器失效，整車能實現(xiàn)MRC，而單中央計算平臺卻存在單點失效。

不是說100%不能做到無單點失效，從工程設計上單域控制器也能實現(xiàn)無單點失效，即域控制器做到失效可運行，也就是常說的fail-operational，只是從系統(tǒng)架構上避免單點失效，工程代價巨大，還不如直接設計副控制器來實現(xiàn)特定條件的MRC。如果是為了集成而集成，不考慮成本、不考慮收益、不考慮架構的藝術，那當我沒說，但凡有個明白的總師都干不出來這事。

其二、筆者和幾個OEM的同仁聊起來中央計算平臺這個話題，吐槽最多的也是不同部門的權益之爭，中央計算平臺明顯是“非我族類”的存在——它不僅吃掉了座艙的大部分功能，還要吃掉底盤的部分功能，最可恨的是它還對ADAS虎視眈眈等等，“我自己能做L3控制器，為啥要集成到你的中央計算平臺里？也不要和我提軟件定義汽車，我們單獨的L3控制器和fallback控制器一樣能快速迭代。

在傳統(tǒng)OEM的組織架構中，整車的EEA團隊和自動駕駛設計并不是一個部門，這種“部門墻”很堅固，很難打破；對于一些新勢力OEM/科技公司而言，組織架構偏平，即沒有所謂的“部門墻”，但是出了問題誰擔責呢？整個中央計算平臺的主責部門又如何判定呢？

其三、就實際產(chǎn)品而言，目前中央計算平臺還僅僅支持行泊一體+座艙+動力+部分底盤功能（比如最簡單的EPB），走的路線基本是“單板多SOC”或者“疊板設計”，從外觀上看是一個集成的控制器，實際上ECU內(nèi)部硬件相對獨立，軟件互相獨立，本質(zhì)上還是一個多ECU封裝到一個ECU內(nèi)的套路，確實是“軟硬分離”！確實是“高內(nèi)聚”“低耦合”！

另外，中央計算平臺目前還是策略上移，原來的控制器的控制策略放在中央計算平臺里，I/O驅(qū)動放在區(qū)域控制器內(nèi)，對于實時性要求不高的舒適性功能還好，對實時性要求高的功能是不可接受的。

其四：可靠性，中央計算平臺的耐久性、老化試驗未經(jīng)驗證，短期內(nèi)集成高階ADS功能存在風險。

基于以上問題，筆者推測，對于L3以上ADS，中央計算平臺是配角，不可能是主角。

三、架構演進的總結(jié)

筆者感觸最深的是架構的正向開發(fā)理念，從工作到生活，貌似這種理念都潛移默化地影響了我的好多思考和決策，筆者認為架構的靈魂在于規(guī)劃，在于布局。一個優(yōu)秀的架構師必須是具備“上可九天攬月”的夸夸其談，“下可五洋抓鱉”的工程落地能力，需要對架構的演進有清晰的認識和判斷，定義好每一代架構的使命，清晰地規(guī)劃上一代如何協(xié)助下一代架構進化，下一代架構又如何利用上一代架構資源，這個資源包括工具鏈、供應鏈、組織架構、ECU硬件、軟件包等等，這是關鍵！

根據(jù)本文節(jié)奏，分布式ADAS架構→域控式ADAS架構→跨域式ADAS架構→跨域冗余式ADS架構→中央式架構，我們總結(jié)一下自動駕駛架構演進路線、每一代架構間的內(nèi)在關聯(lián)和OEM在每個階段的能力布局，國內(nèi)大部分車企都遵循這個路線發(fā)展：

傳統(tǒng)的OEM，基本上都是采用穩(wěn)扎穩(wěn)打的路線，從結(jié)果上看傳統(tǒng)OEM出成績會慢一下，但是每一代架構的升級，傳統(tǒng)OEM都會積累相關領域的經(jīng)驗，甚至轉(zhuǎn)化為企業(yè)標準、設計指導書，作為經(jīng)驗固化下去，不會由于人員的離職導致業(yè)務停滯。

沒有歷史包袱的新勢力則直接跳躍式發(fā)展，短平快地出業(yè)績。對于只有一兩款車的新勢力OEM，這無可厚非，對于想發(fā)展多平臺、多領域車型的新勢力，EEA無疑是他們最大的短板。筆者了解到，一些新勢力對內(nèi)部平臺化設計考慮很少，只看眼前，不考慮長期平臺化，在這個角度看“短平快”策略的后遺癥就暴漏出來了。

架構引發(fā)的產(chǎn)業(yè)鏈重塑

需求的升級導致功能的升級、功能的升級引起頂層架構的進化、最終拉動上下游產(chǎn)業(yè)鏈相互滲透、合作，車載域控制器將打破原有的垂直封閉產(chǎn)業(yè)鏈條，橫向打通融合交叉領域，OEM逐漸從組裝廠演變成Tier1、Tier2、ICT之間的紐帶，協(xié)同Tier1、Tier2、ICT企業(yè)、整合跨界資源，地圖商等企業(yè)，最終搭建集成化的基礎平臺，支撐市場化的服務需求。

（圖片來源：車載智能計算基礎平臺參考架構1.0）

頂層架構的進化致使OEM架構的電子電氣要素升級，引發(fā)域控制器以及外圍傳感器的升級，如毫米波雷達向高分辨率發(fā)展，出現(xiàn)4D毫米波雷達，攝像頭從200萬像素發(fā)展到今天的800萬像素，激光雷達從笨拙的旋轉(zhuǎn)式到小巧的固態(tài)高性能發(fā)展，整個電子電氣架構也將出現(xiàn)新型傳感器形態(tài)，隨著“智能化”時代到來，OEM的話語權勢必越來越大。

批判與尊重

國內(nèi)的新老OEM最常用的戰(zhàn)略路線就是“抄”，特斯拉從Mobileye→英偉達+自研算法→自研FSD芯片+重寫算法的三步戰(zhàn)略仿佛給國內(nèi)OEM指明了路線，蔚小理、智己、路特斯等紛紛站隊英偉達，自研域控制器及算法，畢竟人家英偉達芯片是地表最強，開放度高，而且支持全鏈路的工具鏈，這也無可厚非，但是你們陸陸續(xù)續(xù)地高調(diào)宣布開始“全棧自研”、實現(xiàn)了“全棧自研”，筆者確實看不過去了，只想說：走別人走過的路確實永遠不會迷路，但永遠無法超車！

目前大部分OEM，不論是老牌OEM還是新勢力，熱衷于對標和超越特斯拉，大多并沒有基于“本質(zhì)”思考，毫無平臺規(guī)劃可言，更多是“為了對標而對標”，為了集成而集成，每一個戰(zhàn)略決策大部分不是基于”國情“，而是基于理想主義，反正我先立一個課題，組一個團隊，任命一群領導，概念范XX，量產(chǎn)羅玉鳳，最終給羅玉鳳畫個妝，也就交作業(yè)了。

記得日經(jīng)BP社的報道，特斯拉M3的EEA領先對手6年，特斯拉無疑是行業(yè)的開拓者，不拘泥常規(guī)套路，也無所謂什么“車規(guī)級”，畢竟車規(guī)級標準要求都是行業(yè)大哥（BBA）定的，人家也不屑于在大哥們制定的條條框框里玩耍，筆者認為認知的差距是我們和特斯拉最大的差距，我們擁有頂級的餐廳，頂級的食材，頂級的炊具，但是廚子手藝不行！而特斯拉呢，擁有頂級的廚子和餐廳，然后廚子去尋找合適的食材，設計趁手的炊具，這點我們望塵莫及，也無法復制！

廉頗老矣、尚能飯否？

相比于企圖“亂拳打死老師傅”的造車新勢力，筆者更尊重具有文化底蘊和技術底蘊的傳統(tǒng)OEM，在智能駕駛賽道不斷涌入新玩家，讓整個賽道變得異常浮躁，相比于一些公司的短平快出demo車，秀PPT，傳統(tǒng)OEM具備強大的資源整合能力和雄厚的技術儲備優(yōu)勢，短期看，大OEM的組織變革如大象轉(zhuǎn)身，但長期看，最后的勝利大概率會是老牌OEM。

國外的奔馳寶馬就不多說了，國內(nèi)南有比亞迪北有長城汽車，在汽車“新四化”的較量中，比亞迪的“電動化”已經(jīng)是妥妥行業(yè)一哥，在“智能化”上比亞迪已經(jīng)布局芯片，近期有消息比亞迪和華為在自動駕駛和智能座艙領域展開深度合作，比亞迪必定雄起！

北方的長城汽車也是一匹低調(diào)的黑馬，其自動駕駛路線可以用“雙輪驅(qū)動”來形容，一方面采用全棧自研的內(nèi)部供應商毫末智行提供的系統(tǒng)方案，另一方面使用華為MDC+Momenta算法的軟硬解耦方案，兩種方案同時兼容了L0-L3級別自動駕駛功能，同時具備拓展到L4的能力，得益于長城汽車電子電氣架構平臺化的優(yōu)勢，預計兩種方案對相關系統(tǒng)（轉(zhuǎn)向、制動、HMI）的接口要求做到平臺化設計，域控制器的可移植性、替代性較強。

目前，長城汽車的供應鏈：轉(zhuǎn)向、制動、座艙、智能駕駛基本實現(xiàn)全面自主化，具備自主產(chǎn)權，供貨成本和風險較低、核心控制器采用多家供貨原則，斷貨/延貨風險較小。

關鍵控制器	華為	諾博（長城子公司）	偉創(chuàng)力（外部供應商）	蜂巢新能源（長城子公司）	精工汽車（長城子公司）	博世（外部供應商）	蜂巢易創(chuàng)（長城子公司）
小魔盒1.0			√
小魔盒2.0			√
小魔盒3.0		√
MDC610	√
轉(zhuǎn)向							√
制動					√	√
動力				√
儀表（含HUT）		√				√

由于全球疫情原因，以及芯片危機，同行都爭先恐后站隊英偉達，據(jù)不完全統(tǒng)計，目前選擇英偉達orin的客戶已經(jīng)超過了25家，然而長城汽車選擇了自動駕駛芯片的后起之秀-高通，成為全球首個基于高通芯片平臺的自動駕駛的客戶，如毫末智行的小魔盒3.0，采用了高通9000+高通8540+TC399方案，預計2022Q3量產(chǎn)，據(jù)內(nèi)部人員透漏毫末智行的小魔盒3.0還有B計劃，目的是防止芯片卡脖子，筆者猜測B計劃會采用國產(chǎn)地平線征程5芯片方案。

汽車智能化競爭越來越激烈，最終花落幾家，讓我們拭目以待。

本文參考資料：

《BMW-ADS架構圖》

《特斯拉M3網(wǎng)絡拓撲圖》

《自動駕駛汽車環(huán)境感知》

《知行科技公開演講材料》

《車載智能計算基礎平臺參考架構1.0》

《BMW-ADS_VeCo18_Scalable_Platform_for_AD_FUERST _publish》

《毫末智行公開演講材料》