2萬字長文說清自動駕駛功能架構(gòu)的演進(jìn)

目錄

前言

一、架構(gòu)的藝術(shù)

（一）關(guān)于架構(gòu)的基本概念

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

二、ADAS功能架構(gòu)的演進(jìn)

（一）分布式ADAS架構(gòu)

（二）域控式ADAS架構(gòu)

（三）跨域式ADAS架構(gòu)（行泊一體）

（四）跨域冗余式ADS架構(gòu)（L3和L4的標(biāo)配？）

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

三、架構(gòu)演進(jìn)的總結(jié)

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

批判與尊重

本文參考資料

為什么？

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

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

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

L4架構(gòu)相比L3做了哪些升級？

域控制器為什么通常采用SOC+MCU架構(gòu)方案？

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

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

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

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

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

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

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

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

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

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

一、架構(gòu)的藝術(shù)

（一）關(guān)于架構(gòu)的基本概念

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

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

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

物理（電氣）架構(gòu)：

上圖是整車電器件布置和線束二維布置，看起來線束和電器件密密麻麻布置在二維圖上，通常在OEM叫物理架構(gòu)，有的公司也叫電氣架構(gòu)或者整車電氣拓?fù)洹：诵氖求w現(xiàn)整車電子電氣的布置關(guān)系和連接關(guān)系，主要工作是電氣原理圖設(shè)計、電源分配設(shè)計、搭鐵分配設(shè)計、二維線束走向與三維布置設(shè)計。

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

功能架構(gòu)：

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

系統(tǒng)架構(gòu)：

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

網(wǎng)絡(luò)架構(gòu)（網(wǎng)絡(luò)拓?fù)?/a>）：

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

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

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

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

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

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

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

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

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

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

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

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

二．ADAS功能架構(gòu)的演進(jìn)

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

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

（一）分布式ADAS架構(gòu)

功能架構(gòu)簡介：

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

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

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

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

功能和傳感器的映射關(guān)系如下：

架構(gòu)特點(diǎn)：ECU分散，軟件分散

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

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

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

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

 

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

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

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

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

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

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

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

 安全性：

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

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

（二）域控式ADAS架構(gòu)

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

為啥要多傳感器融合？

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

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

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

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

① 后融合算法，見下圖：

每個傳感器獨(dú)立輸出原始數(shù)據(jù)然后對每個傳感器的數(shù)據(jù)進(jìn)行處理，輸出識別結(jié)果，最后在域控制器內(nèi)設(shè)計合適的傳感器權(quán)重做最終的仲裁?？梢院唵蔚睦斫鉃檫@種感知融合方式類似投票機(jī)制，每個傳感器有不同的話語權(quán)。

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

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

② 前融合算法，見下圖：

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

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

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

  

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

功能架構(gòu)簡介：

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

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

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

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

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

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

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

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

特斯拉為啥刪掉毫米波雷達(dá)？

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

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

選取幾個典型事件進(jìn)行分析：

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

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

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

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

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

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

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

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

域控式ADAS架構(gòu)存在的意義是什么？

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

主流域控制器設(shè)計方案：

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

域控式ADAS架構(gòu)評價：

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

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

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

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

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

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

（三）跨域式ADAS架構(gòu)（行泊一體）

低配版行泊一體功能架構(gòu)圖

功能架構(gòu)介紹：

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

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

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

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

高配版行泊一體功能架構(gòu)圖

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

優(yōu)勢：

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

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

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

系統(tǒng)架構(gòu)如何設(shè)計？

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

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

為啥域控制器通常采用SOC+MCU架構(gòu)方案？

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

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

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

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

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

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

跨域式系統(tǒng)架構(gòu)設(shè)計

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

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

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

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

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

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

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

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

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

上層功能	系統(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	目標(biāo)軌跡預(yù)測模塊	ASIL D	SOC
行車+泊車域	Feature11	規(guī)劃模塊	ASIL D	SOC
行車+泊車域	Feature12	整車控制模塊	ASIL D	SOC/MCU
行車+泊車域	Feature13	故障診斷	ASIL D	SOC/MCU
…	…	…		…

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

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

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

設(shè)計難點(diǎn)

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

（圖片來源：知行科技）

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

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

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

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

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

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

（四）跨域冗余式ADS架構(gòu)（L3和L4的標(biāo)配？）

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

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

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

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

筆者從功能的可用性、安全性兩個維度進(jìn)行特征導(dǎo)出（僅供參考）：

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

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

L3功能架構(gòu)設(shè)計

架構(gòu)解析：

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

主控制器：

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

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

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

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

副控制器：

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

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

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

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

當(dāng)然，只有實力比較強(qiáng)的OEM才能規(guī)劃好這些，沒有架構(gòu)底蘊(yùn)的“新勢力”，很難規(guī)劃好每一代架構(gòu)的遞進(jìn)關(guān)系。

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

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

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

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

L3架構(gòu)的安全考量

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

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

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

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

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

安全策略（示例）：

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

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

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

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

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

寶馬汽車安全策略解析：

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

（圖片來源：BMW-ADS_20181121_VeCo18_Scalable_Platform_for_AD_FUERST _publish）

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

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

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

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

安全方案（獨(dú)家觀點(diǎn)，僅供參考）：

符合功能安全、預(yù)期功能安全的安全架構(gòu)

預(yù)期功能安全考慮：

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

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

功能安全考慮：

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

那么讀者會問，為什么不直接使用激光雷達(dá)的目標(biāo)距離信息呢？

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

對于L3功能架構(gòu)兩個域控制器必須是冗余關(guān)系嗎？

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

電源冗余是必要的嗎？

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

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

供電源頭分析：

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

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

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

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

供電鏈路分析：

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

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

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

OEM當(dāng)家作主

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

L4架構(gòu)相比L3需要做哪些升級？

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

L4架構(gòu)方案預(yù)測

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

主控制器設(shè)計構(gòu)想：

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

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

冗余控制器設(shè)計構(gòu)想：

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

L4設(shè)計和落地的難點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、架構(gòu)演進(jìn)的總結(jié)

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

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

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

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

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

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

（圖片來源：車載智能計算基礎(chǔ)平臺參考架構(gòu)1.0）

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

批判與尊重

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

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

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

廉頗老矣、尚能飯否？

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

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

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

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

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

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

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

本文參考資料：

《BMW-ADS架構(gòu)圖》

《特斯拉M3網(wǎng)絡(luò)拓?fù)鋱D》

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

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

《車載智能計算基礎(chǔ)平臺參考架構(gòu)1.0》

《BMW-ADS_VeCo18_Scalable_Platform_for_AD_FUERST _publish》

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