引言：

前段時間，集度發(fā)布了其首款汽車機(jī)器人ROBO-01，并在發(fā)布會上提到了一個令筆者比較感興趣的詞：“艙駕融合”。其實(shí)早在集度之前，上汽零束也提出過艙駕融合的概念。而有些車企，雖然沒有明確提出艙駕融合，但其智能駕駛和智能座艙產(chǎn)品，也或多或少地有著艙駕融合的形態(tài)。

那么，什么是艙駕融合？目前企業(yè)在艙駕融合上在做怎樣的探索？艙駕融合方案的優(yōu)勢和面臨的挑戰(zhàn)是什么？艙駕融合對開發(fā)模式和產(chǎn)業(yè)鏈格局又會帶來什么樣的影響？帶著這些問題，筆者訪談了相關(guān)領(lǐng)域的技術(shù)專家，希望能夠?qū)Α芭擇{融合”有更深層次的理解。

1. 厘清“艙駕融合”概念

眾所周知，汽車的智能化程度取決于底層的EE架構(gòu)。在汽車智能化的進(jìn)程中，EE架構(gòu)的發(fā)展路線從功能獨(dú)立的分布式架構(gòu)，到功能集成的域集中式架構(gòu)，最后再到高度集成的中央計(jì)算＋區(qū)域控制的中央集中式架構(gòu)。

在域集中式架構(gòu)階段，業(yè)內(nèi)談的比較多的就是經(jīng)典五域：座艙域、智駕域、動力域、底盤域、車身域。再往后發(fā)展，到域融合階段，五大功能域之間開始嘗試進(jìn)行跨域融合，雖然不同的主機(jī)廠有不同的理解和做法，但大體思路是一致的，即先將部分域的功能集成到一個高性能計(jì)算單元內(nèi)，再逐漸聚合更多的功能域，最終實(shí)現(xiàn)1個中央計(jì)算大腦的目標(biāo)。艙駕融合差不多就是在這個階段誕生的產(chǎn)物—— 座艙域和智能駕駛域進(jìn)行跨域融合，形成艙駕一體域控制器。

不同形式的跨域融合嘗試 （信息來源：公開資料整理）

均聯(lián)智行首席架構(gòu)師汪浩偉認(rèn)為：“艙駕融合可以從硬件和軟件兩個不同的層面去考慮，從不同層面進(jìn)行融合的概念是完全不同的，目的和作用也完全不一樣。

“硬件上的融合更多地是基于產(chǎn)品的視角，從成本和設(shè)計(jì)的維度進(jìn)行考慮。在一顆SoC芯片里面做融合，才是真正意義上的硬件融合。這個時候，底層軟件和通訊方式都會有本質(zhì)上的改變，成本上的優(yōu)勢也會凸顯出來。

“軟件上的融合更多地是基于技術(shù)的視角，從功能的維度進(jìn)行考慮。軟件上的融合需要考慮怎么去改變整體軟件架構(gòu)設(shè)計(jì)，從而使得新的軟件架構(gòu)能夠更加適用于艙駕融合系統(tǒng)。與此同時，引入SOA面向服務(wù)的設(shè)計(jì)理念和工具，可以幫助主機(jī)廠更好地做好艙駕融合。

“軟件上的融合不會隨著硬件上的融合而變化。不管硬件是做成一個單SoC芯片，還是做成一個單板，亦或是做成兩個單板，從軟件融合的角度來講，區(qū)別并不大，只是底層的通訊和運(yùn)行方式會有所不同。從功能層面來講，只有軟件上的融合才會改變應(yīng)用程序和上層邏輯本身，艙駕融合意義才會更大。”

1.1 艙駕融合層級的劃分

1）應(yīng)用層面的融合

由于技術(shù)發(fā)展和工程化的問題，現(xiàn)階段比較容易實(shí)現(xiàn)的方案是：在物理形式上，智能駕駛域控制器和座艙域控制器采用完全相互獨(dú)立的兩個盒子，但在應(yīng)用層面，很多功能之間的信息交互通過跨域進(jìn)行打通，并實(shí)現(xiàn)數(shù)據(jù)融合創(chuàng)新 —— 將智能座艙中的人機(jī)交互、沉浸式體驗(yàn)等內(nèi)容，與智能駕駛的各項(xiàng)功能深度結(jié)合、聯(lián)動，從而提升用戶的安全感與舒適感，增強(qiáng)用戶對智能化汽車的使用體驗(yàn)。

環(huán)宇智行COO曹晶提到，他們有一個項(xiàng)目，主機(jī)廠要求統(tǒng)一采用SOA架構(gòu)，通過以太網(wǎng)或CAN協(xié)議把座艙域和智駕域中的信號能夠發(fā)送出來共享，這樣一來，在功能層面就可以做更多的融合創(chuàng)新。如果按以前的策略，兩個域的信號基本都是固定寫死的，雖然可以通過私有CAN轉(zhuǎn)發(fā)到整車CAN總線上，但是，系統(tǒng)需要獲取相關(guān)信號的時候，還得再去整車CAN總線上查詢，非常不方便。

2）座艙域控制器和智駕域控制器在物理形式上合二為一

座艙域控制器和智駕域控制器合并成一個盒子，內(nèi)部由多個SoC或者MCU芯片構(gòu)成。這些芯片用于支持不同的功能，每個芯片以及芯片內(nèi)的不同核上運(yùn)行不同的操作系統(tǒng)。這種形式又可再細(xì)分成兩種方案：A. 座艙和智駕功能分別部署在不同的板子上。B.座艙和智駕功能部署在同一個板子上。

“如果座艙和智駕功能分別部署在不同的板子上，用于支持座艙和智駕功能的SoC芯片肯定都會有自己專屬的外圍電路設(shè)計(jì)；如果兩者的功能部署在同一個板子上，設(shè)計(jì)方案可以從整體上去考量，包括器件的選型，電路、供電、存儲等方面的設(shè)計(jì)，比如，考慮DDR是否可以共享、EMMC模塊是否可以共享等等。整體來講，B方案比A方案在電子器件、接口、線束等部件的使用量上有一定程度的減少，使得BOM成本相對較低?！辈芫П硎?。

3）基于單SOC芯片的艙駕功能融合

智艙和智駕的功能由一顆單SoC芯片來完成 —— 在芯片上運(yùn)行虛擬機(jī)，通過虛擬機(jī)分割出不同的功能模塊，來實(shí)現(xiàn)不同安全級別需求的艙駕功能。

目前，有一些芯片公司和主機(jī)廠在探討這樣的方案，未來也很有可能會有這樣的一些芯片產(chǎn)品出現(xiàn)。但是，理想很豐滿，現(xiàn)實(shí)很骨感，短期內(nèi)應(yīng)該是很難看到這樣的理想方案落地。

據(jù)業(yè)內(nèi)專家透露，大部分車型無論是對于成本，還是可靠性都比較敏感。同樣，開發(fā)一個新車型，車型的上市周期也會有一定的要求，所以主機(jī)廠一般會首選技術(shù)成熟度較高，并且成本已經(jīng)在行業(yè)內(nèi)能夠被分?jǐn)傁聛淼某墒旆桨?。另外，不管是主機(jī)廠的組織架構(gòu)，還是對應(yīng)用層的梳理，都需要很長時間去調(diào)整和消化。因此，這樣的產(chǎn)品需求不會一下子就爆發(fā)出來。

1.2 什么是真正的艙駕融合？

芯片作為汽車智能化的核心硬件，在很大程度上影響著智能座艙和智能駕駛的能力上限。因此真正的艙駕融合需要智艙與智駕芯片一體化，即智艙與智駕的軟件和算法完全部署在同一顆SoC芯片上，這是最理想的方案。但受限于軟硬件技術(shù)水平、架構(gòu)方案、供應(yīng)鏈等方面的原因，目前還難以實(shí)現(xiàn)基于單SOC芯片的艙駕融合方案。

映馳科技產(chǎn)品副總裁趙建洪講到：“我們首推的是艙泊融合方案，并且，主機(jī)廠對艙泊融合也有一定的需求。因?yàn)椴窜嚪桨脯F(xiàn)在比較成熟，同時，座艙域控制器上的算力也有了一定的富余，把泊車功能融合到座艙域控制器具有一定的成本優(yōu)勢。不過，艙泊融合相當(dāng)于是艙駕融合的第一步，由于行車方案目前還不是很成熟，需要兩者都發(fā)展成熟的時候，再去考慮融合的問題?！?/p>

汪浩偉也提到了類似的觀點(diǎn)：“座艙和智駕集成在一個單SoC芯片里面，肯定是大勢所趨的。在成本的驅(qū)動下，這種方案大概率會從中低端的車型開始出現(xiàn)（艙泊一體）。待EE架構(gòu)進(jìn)化到中央集成+區(qū)域控制架構(gòu)階段，并且業(yè)內(nèi)逐漸地把底層軟件鋪設(shè)好，最后才能看到兩者融合所帶來的真正價值?！?/p>

為什么依然有企業(yè)有動力去做兩者的融合？因?yàn)樵趹?yīng)用層面上，兩者之間可以互相借力。之所以現(xiàn)在艙駕融合的應(yīng)用價值還沒有被完全挖掘出來，是因?yàn)榈讓拥能浖O(shè)計(jì)還沒達(dá)到相應(yīng)的程度，需要將底層的邏輯進(jìn)行封裝，比如，做成一個個微服務(wù)的形式。在這樣的情況下，座艙和智駕之間就可以更容易地去相互調(diào)用對方的服務(wù)或者資源，進(jìn)而就能夠比較容易地去開發(fā)新的融合應(yīng)用?！?/p>

1.3 在什么階段，艙駕才有必要融合？

智能座艙和智能駕駛，作為汽車智能化的代表，直接影響車主對汽車智能化的體驗(yàn)。智能座艙是汽車直接與用戶溝通、交流的部分，體現(xiàn)的是人與車的交互；智能駕駛則發(fā)揮汽車最基本的功能，即行駛，體現(xiàn)的是車與環(huán)境的交互。而在交通環(huán)境中，駕駛行為是人-車-環(huán)境三方交互的過程，因此，汽車作為重要的載體，如何打通三方的交互，讓駕駛員和乘客獲得好的駕乘體驗(yàn)，就顯得尤為重要。

那么，艙駕融合在什么階段才更有意義，是L3級以上，還是L3級及以下？在訪談的過程中，筆者發(fā)現(xiàn)大家的理解目前也存在差異 —— 有的人認(rèn)為，在L3級及以下才有必要融合；也有的人認(rèn)為，在不同的自動駕駛階段都有必要融合，只不過融合的形式和意義不同而已。

1）觀點(diǎn)1 ：只有在L3級及以下融合才有意義

在L3及以下的時候，系統(tǒng)只是輔助駕駛，駕駛員還是要對車輛的安全負(fù)責(zé)。人坐在艙內(nèi)，對艙外的行車環(huán)境并不一定能夠充分了解，因而，只有座艙和智駕進(jìn)行信息打通和融合，座艙才能更清楚地了解自動駕駛系統(tǒng)在干什么，艙外的環(huán)境是怎樣的。座艙結(jié)合智駕的一些傳感器數(shù)據(jù)信息，才能更好地把車外的環(huán)境信息反饋給駕駛員，幫助或指導(dǎo)駕駛員更好地開車。

當(dāng)自動駕駛等級達(dá)到L4的時候，人就脫離了駕駛?cè)蝿?wù)，座艙里面的人就不再需要關(guān)心車外的情況，整個座艙會變成一個以娛樂和工作為中心的“第三生活空間”。這個時候，自動駕駛系統(tǒng)就基本沒有必要介入到座艙 —— 如果駕駛?cè)蝿?wù)都已經(jīng)完全交給系統(tǒng)去完成了，自動駕駛系統(tǒng)還時不時地去“煩”座艙里的人，那這還算是真正的“自動駕駛”么？

2）觀點(diǎn)2 ： 都有必要融合，只不過兩者融合的形式和深度不一樣

A. L3及以下 - 硬件獨(dú)立，上層應(yīng)用融合

對于L3及以下 ，硬件層面可能并不需要融合，只是在上層應(yīng)用層面基于一些信息的交互，做一些融合類的功能。

目前，應(yīng)用在座艙和智駕的一些芯片，比如應(yīng)用在座艙上的高通8155、智駕上的TI TDA4，經(jīng)過這兩年的產(chǎn)業(yè)化路徑已經(jīng)變得非常成熟，在硬件相互獨(dú)立的前提下，底層就不需要再做太多的工作，因此就不需要過多的工程化的投入或者是成本上的增加，通過虛擬現(xiàn)實(shí)或一些其它的方式，就可以在應(yīng)用層打造出一些更加沉浸式的體驗(yàn)。例如，人工智能語音公司Cerence Inc發(fā)布的Cerence Look，結(jié)合了在線數(shù)據(jù)庫和視線跟蹤攝像頭數(shù)據(jù)，將汽車的語音助手變成實(shí)時導(dǎo)游。駕駛員不需要使用特定的喚醒詞，而是使用環(huán)境重建和傳感器數(shù)據(jù)來確定車輛的位置，并確定駕駛員提出問題時正在看什么。

B. L4級 - 軟硬件均開始融合

在EE架構(gòu)集中化、芯片算力的大幅提高以及軟件開發(fā)能力提升的不斷推動下，智駕和智艙從底層硬件層面開始進(jìn)行融合。而應(yīng)用層級的融合是車輛功能和性能的外在表現(xiàn)形式，又會受到底層硬件和軟件的制約。只有底層硬件和軟件融合得足夠深，上層應(yīng)用才有可能發(fā)揮出最大的融合效果。

當(dāng)自動駕駛發(fā)展到L4級，即無人駕駛階段，人從駕駛?cè)蝿?wù)中解放出來，汽車本身成為服務(wù)的載體，座艙的設(shè)計(jì)思路將從以駕駛員為核心轉(zhuǎn)向以乘客為核心。那么，座艙和智駕之間的融合應(yīng)用也將從提供輔助駕駛相關(guān)的信息為主，轉(zhuǎn)變?yōu)橐蕴峁┥罘?wù)相關(guān)的信息為主。在這個階段，儀表或者HUD上便不再需要顯示一些駕駛員接管的提醒或其它一些用于輔助駕駛的圖像信息（比如用于泊車的360全景信息顯示），更多地會展示一些娛樂和工作相關(guān)信息（比如，基于車外的攝像頭數(shù)據(jù)在艙內(nèi)展示一些車外的風(fēng)景信息等）。

2. 艙駕融合的初步嘗試 - 特斯拉

特斯拉是中央計(jì)算+區(qū)域控制理念的最早實(shí)踐者，其在2019年量產(chǎn)的Model3車型中率先采用了此架構(gòu)。其中，中央計(jì)算單元CCM融合了影音娛樂模塊（座艙）、駕駛輔助系統(tǒng)模塊（智駕）以及車內(nèi)外通信信通模塊，只不過三個模塊分別部署在不同的板子上，運(yùn)行著各自獨(dú)立的操作系統(tǒng)，這算是艙駕融合形式在早期的一個初步嘗試。

2.1 特斯拉艙駕融合方案簡介

中央計(jì)算平臺（CCM）的硬件構(gòu)成（參考2021款ModelS）：

A.信息娛樂控制單元的主控芯片（更換至第三代）：AMD Ryzen YE180FC3T4MFG

B. 駕駛輔助系統(tǒng)控制單元的主控芯片：2個自研FSD

C. 車內(nèi)外通信系統(tǒng)控制單元的主控芯片：高通SA415M

特斯拉中央計(jì)算模塊CCM內(nèi)部電路板組構(gòu)成 （圖片來源：UBS Evidence Lab）

在軟件層面：

A.信息娛樂控制單元采用自研的車機(jī)操作系統(tǒng)，它基于開源的 Linux 操作系統(tǒng)進(jìn)行定制開發(fā)。

B.駕駛輔助系統(tǒng)控制單元上的MCU運(yùn)行FreeRTOS，SoC上采用基于Linux進(jìn)行深度定制開發(fā)的Version操作系統(tǒng)。

2.2 特斯拉艙駕融合方案的優(yōu)勢

1）更高效的通訊

座艙和智駕分屬于兩個不同控制器的時候，兩者之間需要通過CAN或者以太網(wǎng)總線進(jìn)行通訊；而現(xiàn)在，兩者雖然還是部署在不同的PCB板子上，但是可以部署在一個盒子里面，兩個板子之間通過Switch就可以實(shí)現(xiàn)通訊，通訊速率更高。

2）共用一套散熱系統(tǒng)，節(jié)省成本

現(xiàn)在座艙和智駕需要實(shí)現(xiàn)的功能越來越多，所需的算力越來越大，功耗也越來越高，因此座艙域控制器和智能駕駛域控制器都需要做散熱設(shè)計(jì)。尤其是對于大算力的智駕域控制器，還需要做專門的水冷散熱設(shè)計(jì)。如果兩者放在一個盒子里面，散熱系統(tǒng)就無需再做兩套，可直接共用一套冷卻系統(tǒng)。

3）節(jié)省空間，易于布置

集成到一個盒子里，比較容易布置，并且整車空間利用率也會更高。

單單上面的幾點(diǎn)好處，大家肯定也會覺得有點(diǎn)單薄——不足以驅(qū)動特斯拉去采用這樣的方式，那么特斯拉采用這種方案背后真正的驅(qū)動力是什么呢？

據(jù)業(yè)內(nèi)專家透露，特斯拉并不只是為了實(shí)現(xiàn)艙駕融合，才要做個CCM模塊把座艙和智駕的兩個板子放在一起， 其真正的目的是為了實(shí)現(xiàn)中央計(jì)算+區(qū)域控制器的架構(gòu)。而中央計(jì)算平臺則需要整合其它功能域的功能，但受當(dāng)時軟硬件水平、架構(gòu)方案等限制，即便是特斯拉也沒辦法將主要的域控融合到一顆SoC芯片上，但至少把他們都集成到了一個盒子里面去，這也算是比較有意義的一次初步探索。

雖然特斯拉的這代架構(gòu)并不是真正意義上的中央計(jì)算+區(qū)域控制器架構(gòu)，但當(dāng)時也是業(yè)內(nèi)公認(rèn)的最先進(jìn)的EE架構(gòu)，被認(rèn)為是領(lǐng)先同行至少5~6年。特斯拉采用這樣的EE架構(gòu)，背后的驅(qū)動力就是為了實(shí)現(xiàn)軟硬分離、軟件定義汽車——通過采用區(qū)域控制器，把硬件剝離掉，并把硬件的變化隱藏在區(qū)域控制這層，使得中央大腦能夠做到與硬件相對“無關(guān)”，真正的地用軟件去控制車輛的各個方面。

2.3 為什么很少有其它主機(jī)廠去效仿特斯拉的艙駕融合方案？

特斯拉這種把座艙和智駕模塊放在一個盒子里面，從表面上看，感覺技術(shù)難度也不大，為什么到現(xiàn)在依然很少有其它主機(jī)廠去效仿特斯拉，是否存在一些技術(shù)壁壘和局限性，導(dǎo)致沒有實(shí)力的主機(jī)廠想模仿卻模仿不了，而有實(shí)力的主機(jī)廠因?yàn)槠渲械木窒扌远x擇了去規(guī)劃其它方案？

2.3.1 特斯拉艙駕融合方案的技術(shù)壁壘

1）電磁干擾設(shè)計(jì)有難度

特斯拉的CCM模塊內(nèi)，因?yàn)椴煌遄又g都是高速信號在傳輸，板子之間會存在電磁互相干擾的潛在問題，怎樣消除不同板子之間的電磁干擾會存在一定的難度。

2）需要對整個系統(tǒng)架構(gòu)有很深的理解

某主機(jī)廠智能駕駛系統(tǒng)架構(gòu)專家講道：“特斯拉的整個系統(tǒng)架構(gòu)都是自研的，包括它的子系統(tǒng)和關(guān)聯(lián)系統(tǒng)。怎么去設(shè)計(jì)硬件架構(gòu)和軟件架構(gòu)、需要預(yù)留哪些接口、在前期都需要考慮得非常清楚。然而，在國內(nèi)能夠把座艙、智能駕駛和整車控制這三大部分都能想明白的OEM幾乎沒有。”

2.3.2 特斯拉艙駕融合方案的局限性

1）不適合平臺化應(yīng)用

傳統(tǒng)的主機(jī)廠面向的用戶更多，價格區(qū)間更廣，從十幾萬到二十幾萬，再到三十幾萬及以上的車型都有；并且，一種車型還要做高中低不同配置。所以，特斯拉當(dāng)前的這種艙駕融合方案，對于大多數(shù)需要考慮平臺化的傳統(tǒng)車企并不一定適用。

汪浩偉解釋道：“特斯拉的車型比較少，在考慮EE架構(gòu)應(yīng)用的時候，首先是要從車型本身的競爭力的角度去考慮，不會考慮太多平臺化，所以軟件設(shè)計(jì)上基本也沒有什么平臺化的概念。如果換成是大眾，有這么多品牌，各個品牌旗下又有那么多車型，那么他在做EE架構(gòu)的時候，一定會去考慮平臺化的問題，正所謂‘大象難轉(zhuǎn)身’，它在推進(jìn)這樣一個新EE架構(gòu)的時候，面臨的困難必然更多?！?/p>

2）不具備較強(qiáng)的擴(kuò)展性

特斯拉的CCM模塊在當(dāng)初量產(chǎn)時的確算是比較先進(jìn)的產(chǎn)品，但智駕和智艙都是處在快速地發(fā)展迭代中，對算力的需求也越來越大；因而，站在現(xiàn)在這個時間點(diǎn)上來看，特斯拉CCM模塊的算力資源就有點(diǎn)捉襟見肘，同時，受其硬件結(jié)構(gòu)形式的限制，它又很難在原來的基礎(chǔ)上進(jìn)一步擴(kuò)充算力資源。

創(chuàng)時智駕首席產(chǎn)品專家楊曾提到：“如果考慮擴(kuò)展性，軟件還可以通過OTA更新來實(shí)現(xiàn)，但是艙駕融合域控制器硬件的可擴(kuò)展性如何實(shí)現(xiàn)？如果前期能夠?yàn)樽摵椭邱{預(yù)留足夠多的接口和算力資源，那么后期也許還可以逐漸增加新的功能。但現(xiàn)實(shí)是，座艙和智能駕駛技術(shù)都還處于不斷地發(fā)展中，尤其是智能駕駛，迭代速度更快，前期很難把規(guī)劃做得完美無缺，若后期再改動，其設(shè)計(jì)和平臺驗(yàn)證都需要很多的時間和資源投入?！?/p>

3. 國內(nèi)企業(yè)艙駕融合方案的探索

3.1 Tier1

1）德賽西威

基于多SoC芯片的艙駕融合方案

2022年4月，發(fā)布車載智能計(jì)算平臺“Aurora”—— 實(shí)現(xiàn)從了從域控制器向中央計(jì)算平臺的跨越。

在硬件層面，該中央計(jì)算平臺搭載英偉達(dá)Orin、高通SA8295和黑芝麻華山A1000三大SoC芯片；在功能層面集成智能座艙、智能駕駛、網(wǎng)聯(lián)服務(wù)等多個功能域；在結(jié)構(gòu)形式上采用插拔式結(jié)構(gòu) —— 算力可伸縮配置，用于滿足不同價位車型的多樣化需求。

德賽西威中央計(jì)算平臺Aurora （圖片來源：德賽西威公開宣講材料）

2）創(chuàng)時智駕

基于多SoC芯片的艙駕融合方案（據(jù)推測）

在硬件層面，正在規(guī)劃兩類高性能的艙駕一體域控制器：基于J5系列芯片和基于Orin系列芯片；在軟件層面考慮采用成熟的中間件軟件平臺、支持多域融合的CarOS軟件框架和支持應(yīng)用軟件開發(fā)的安全組件產(chǎn)品Safety Copilot。

創(chuàng)時智駕域控制器產(chǎn)品規(guī)劃 （圖片來源：創(chuàng)時智駕公開宣講材料）

3）中科創(chuàng)達(dá)

A.基于高通SA8295的艙泊融合方案（座艙和泊車功能融合）

2022年初，發(fā)布基于高通SA8295芯片的硬件平臺，實(shí)現(xiàn)一芯多屏座艙域控方案，并在高算力（CPU算力200K DMIPS、GPU算力3000G FLOPS、 NPU算力30 TOPS）和多攝像頭支持能力下，實(shí)現(xiàn)座艙和低速泊車功能的融合，支持360°環(huán)視和智能泊車功能。

B. 基于高通SA8795芯片的艙駕融合方案（座艙和智駕功能融合）

基于高通SA8795芯片（預(yù)計(jì)，CPU算力240K DMIPS、 NPU算力60 TOPS）布局座艙和智能駕駛的跨域融合方案，并計(jì)劃于2024年實(shí)現(xiàn)量產(chǎn)。

3.2 主機(jī)廠

1）小鵬

A 。 應(yīng)用層級的融合 —— SR智能輔助駕駛環(huán)境模擬

該技術(shù)是基于高德第三代車載導(dǎo)航實(shí)現(xiàn)的。在技術(shù)方案上，將導(dǎo)航與高精地圖深度融合，并將智駕系統(tǒng)的感知、決策信息與車道級導(dǎo)航更加精準(zhǔn)地匹配。

在NGP功能激活的狀態(tài)下，小鵬可以實(shí)現(xiàn)“SR智能輔助駕駛環(huán)境模擬”，將環(huán)境感知、定位、高精地圖和高清渲染的畫面融合，模擬真實(shí)的路況。SR（Surround Reality）系統(tǒng)能夠展現(xiàn)駕駛員和智駕系統(tǒng)的責(zé)任邊界，并提供準(zhǔn)確的風(fēng)險場景識別和清晰的分級接管提醒，告知駕駛員接管車輛的時機(jī)，增強(qiáng)人機(jī)共駕的安全性與可靠性。

小鵬SR系統(tǒng) （圖片來源：小鵬汽車獲2022年度德國iF設(shè)計(jì)三項(xiàng)用戶體驗(yàn)大獎 （baidu.com））

B. 基于多SoC芯片的艙駕融合方案（據(jù)推測）

艙駕一體域控制器示意圖 （圖片來源：小鵬公開宣講材料）

小鵬G9艙駕融合方案：上一代的中控系統(tǒng)CDU、儀表系統(tǒng)ICM和智駕系統(tǒng)XPU，在此方案中會整合到一個艙駕一體域控制器中。

2）上汽零束

基于多SoC芯片的艙駕融合（據(jù)推測）

在上汽零束的全棧3.0架構(gòu)中，硬件平臺方面由兩個HPC高性能計(jì)算單元HPC1和HPC2以及四個區(qū)域控制器（ZONE）構(gòu)成。其中一個HPC高性能計(jì)算單元融合了座艙和智駕功能。在軟件層面，通過中間件和SOA原子服務(wù)層，使得向上能夠提供統(tǒng)一、標(biāo)準(zhǔn)的API接口，能夠讓應(yīng)用層開發(fā)更輕松，復(fù)用性更高。

銀河全棧3.0軟件平臺 （圖片來源： 上汽零束宣講資料）

3）集度汽車

應(yīng)用層級的融合 —— 集度發(fā)布的艙駕融合，主要體現(xiàn)在兩個方面的應(yīng)用：一是智能駕駛“真冗余”的方案，二是3D人機(jī)共駕地圖。

A. 智能駕駛“真冗余”方案

集度的智駕“真冗余”是指當(dāng)智駕域控失效時，智艙域控可以順利接管車輛，起到冗余備份的作用。具體來說，就是將12個攝像頭中的1個前視攝像頭接入到智艙域，從而在緊急情況下，智艙的域控制器可以基于該攝像頭的路況感知信息，實(shí)現(xiàn)緊急制動或者靠邊停車功能。

B. 3D人機(jī)共駕地圖

集度在座艙內(nèi)基于現(xiàn)實(shí)環(huán)境通過仿真建模為駕駛員構(gòu)建了一個虛擬的駕駛世界，實(shí)現(xiàn)靜態(tài)地圖導(dǎo)航和動態(tài)感知數(shù)據(jù)融合，打通虛擬場景與現(xiàn)實(shí)交通環(huán)境的障礙。從集度發(fā)布的視頻來看，通過智能座艙和智能駕駛系統(tǒng)之間的跨域資源調(diào)度，智能駕駛系統(tǒng)感知到的障礙物模型支持直接可視化融合顯示在 3D 地圖上，提供了還原現(xiàn)實(shí)的虛擬化駕駛體驗(yàn)。

4 。 單SoC芯片的艙駕融合方案

特斯拉目前采用的方案屬于艙駕融合的一個初期探索，只是把座艙和智駕的域控制器合二為一集成在一個盒子里面。以后，如果能夠?qū)崿F(xiàn)真正的艙駕融合——把座艙和智駕的功能完全集成在一顆SoC里面來實(shí)現(xiàn)。這樣的方案又會帶來哪些好處？同時，實(shí)現(xiàn)這樣的方案又將面臨怎樣的挑戰(zhàn)？

4.1 單SoC芯片方案帶來的好處

1） 成本可以做得更低

芯片的集成化程度更高，物料用的更少，相比于之前用多個芯片方案的成本，可以有一定程度的降低。

部分底層軟件可以共用，可以節(jié)約一部分底層軟件的開發(fā)成本或購買成本。

2）通訊時延更短

相比于之前通過網(wǎng)絡(luò)總線傳輸?shù)姆绞交騼蓚€板子件通過Switch通訊，現(xiàn)在可以使用內(nèi)存共享的方式，通訊時延會更短。

3）OTA升級空間更大

某主機(jī)廠自動駕駛系統(tǒng)架構(gòu)專家認(rèn)為：“艙駕融合后，數(shù)據(jù)信息可以共享，兩者之間的交互可以做得更多，軟件迭代的想象空間會更大。如果兩個域還是完全獨(dú)立，接口基本上是固定的，接口變，雙方軟件就要跟著變，比如在后期，一些主機(jī)廠會要求增加一個新功能，就需要訂閱一些服務(wù)，會發(fā)現(xiàn)訂閱不了，因?yàn)橹暗慕涌谑嵌x“死”的，除非在開始的時候就能夠把接口定義得特別豐富，否則，一旦后期需要做變更，就需要跨部門提變更需求，再次跨部門進(jìn)行協(xié)作，溝通成本很高。如果兩者融合了，再增加新的功能，一般只需要對軟件模塊做一些變更，不再需要變更硬件接口，便于在后期做一些系統(tǒng)上的OTA升級?！?/p>

“座艙域控制器和智能駕駛域控制器相互獨(dú)立的時候，他們之間可互通的信息比較少，也很難及時獲取對方的數(shù)據(jù)信息，但艙駕融合以后，兩者的傳感器數(shù)據(jù)便可以更充分、更及時地被復(fù)用。相當(dāng)于在功能層面留下更多的想象空間 —— 基于座艙和智駕的這些傳感器數(shù)據(jù)，可以融合出一些比較新的、有想象力的應(yīng)用。” 楊曾說道。

4.2 單SoC芯片方案面臨的挑戰(zhàn)

4.2.1 硬件層面的挑戰(zhàn)

1）芯片本身的設(shè)計(jì)

實(shí)現(xiàn)真正的艙駕一體融合方案，SoC芯片設(shè)計(jì)本身就是個很大的難題 —— 要把很多的系統(tǒng)和功能融合在一起，芯片的設(shè)計(jì)方案會很復(fù)雜。同時，單SoC芯片不僅要實(shí)現(xiàn)上千TOPS的算力，還要把功耗控制在可接受的程度內(nèi)，這對芯片的制程要求非常高?，F(xiàn)在的車載AI芯片已經(jīng)下探到5nm了，不僅成本高，而且掌握這種先進(jìn)工藝的企業(yè)也寥寥無幾。

有業(yè)內(nèi)人士提到了使用Chiplet來設(shè)計(jì)這樣的SoC芯片，它的優(yōu)勢在于各家芯片廠商可以專注自己的芯粒和IP，不用為多余的IP買單，并且小芯粒的流片良率更高，有壞點(diǎn)的部分扔掉，剩下的還能用。因此，采用小芯粒技術(shù)進(jìn)行SoC芯片的迭代設(shè)計(jì)會更加方便。但是，目前也存在一些問題 ——

Chiplet技術(shù)，又被稱為小芯粒技術(shù)，即把不同制程的芯粒經(jīng)過選型直接封裝在一個SOC里面。目前業(yè)內(nèi)已有一些成功的應(yīng)用案例，并且整個行業(yè)也在推動。曹晶告訴九章智駕：“基于Chiplet技術(shù)實(shí)現(xiàn)艙駕融合的SoC芯片不難被設(shè)計(jì)出來，只要產(chǎn)業(yè)鏈端能夠提供足夠多滿足智駕和智艙的芯粒就可以。 我覺得使用芯粒技術(shù)最大的挑戰(zhàn)不在單個芯粒內(nèi)部的這些設(shè)計(jì)和實(shí)現(xiàn)，反倒是高速帶寬部分，畢竟芯粒之間也是需要進(jìn)行大通道數(shù)據(jù)的輸入輸出。

“同樣，Chiplet技術(shù)不僅面整個產(chǎn)業(yè)鏈成熟的問題，而且在SoC芯片上面實(shí)現(xiàn)智艙和智駕這些復(fù)雜功能也會涉及到很多工程化的問題，這些問題可能會比把芯片設(shè)計(jì)出來所花的時間還要長。整個行業(yè)討論這種技術(shù)方案比較多，在實(shí)踐上也有企業(yè)在向這個方向發(fā)展，但是我覺得離真正在車上量產(chǎn)應(yīng)用尚且需要一段時間，不過至少這個方向的國產(chǎn)自主化趨勢是窺見一斑了?！?/p>

2）硬件資源分配

智艙和智駕功能融合在一個單SoC芯片里面，芯片內(nèi)部的GPU和CPU等資源可以共享，但是資源該如何分配？哪一塊GPU/CPU資源供智能駕駛使用，哪一塊GPU/CPU資源供座艙使用，怎樣實(shí)現(xiàn)資源的動態(tài)調(diào)節(jié)？并且，智艙和智駕都處于不斷地迭代發(fā)展中，如果智能駕駛發(fā)展兩年，技術(shù)迭代升級了，對硬件的需求變了，之前硬件資源分配方案可能就不行了，還需要重新做資源分配。

同時，對于單SoC芯片的艙駕融合方案，很有可能要做內(nèi)存共享，這樣數(shù)據(jù)才會讀得更快，信息傳輸延遲會更小。但是，DDR分配也會面臨很多問題 —— 比如，智駕的內(nèi)存需求發(fā)生變更，另外一個也要跟著變更；在座艙開發(fā)的時候，內(nèi)存損壞，也會影響到自動駕駛的開發(fā)。

某主機(jī)廠自動駕駛系統(tǒng)架構(gòu)專家告訴九章智駕：“當(dāng)前，座艙和智駕尚未達(dá)到一個終極形態(tài)，硬件資源也沒有足夠強(qiáng)。兩者在硬件資源需求上的變動很可能會影響到整個軟件架構(gòu)，以及后續(xù)硬件資源的分配。比如，對于CPU資源，有些ARM核用于支持座艙相關(guān)應(yīng)用，有些ARM核用于支持智能駕駛相關(guān)應(yīng)用；對于GPU資源，可能會通過制定一個優(yōu)先級進(jìn)行資源使用或者直接把GPU隔離成不同部分，座艙用一部分、智駕用另外一部分；但問題的關(guān)鍵是 - 對于這種架構(gòu)設(shè)計(jì)，大家都沒有太多經(jīng)驗(yàn)可以借鑒，比如，硬件資源怎么去分配，分配是否合理？后期面臨需求變更的時候，會不會沒辦法實(shí)現(xiàn)？這些問題都會存在很大的不確定性?！?/p>

“智能座艙和智能駕駛功能集成在單顆SoC芯片上的時候，因?yàn)閮蓚€域的需求完全不同，在做硬件資源分配的時候，既要定義這些應(yīng)用的優(yōu)先級，又要確保這些應(yīng)用有足夠資源可以用 —— 能夠保證互相不打架，也不能出現(xiàn)一個應(yīng)用鎖死另外一個應(yīng)用的現(xiàn)象?！蓖艉苽ケ硎?。

3）行駛安全考慮

某芯片公司負(fù)責(zé)人告訴九章智駕：“一旦具備L3以上的自動駕駛功能，智能座艙與智能駕駛在底層芯片上，我個人觀點(diǎn)一定會分離，原因有：智能駕駛外接大量各類傳感器，要求大算力，要求芯片，OS，相應(yīng)軟件硬件都具備功能安全，根本不充許運(yùn)行中出現(xiàn)死機(jī)停機(jī)等故障，同時相應(yīng)的軟件種類也少，不會讓用戶去隨便下載什么智能駕駛功能軟件。而智能座舵就是一個大手機(jī)，不考慮大屏的價格，成本低很多，但同時需要支持各種應(yīng)用軟件的下載及運(yùn)行，但芯片os，軟件硬件又不具備功能安全。一旦兩者運(yùn)行在同一個芯片及OS上，盡管軟件的隔離比較容易做好（通過Hypervisor技術(shù)），但芯片底層硬件的相互隔離很難做好。一旦座艙軟件卡死涉及底層硬件，一定會影響駕駛軟件的運(yùn)行。同時一旦出了問題，追責(zé)很難。座艙軟件用戶可以隨意下載運(yùn)行，一旦這些沒有經(jīng)過測試的運(yùn)應(yīng)用軟件運(yùn)行導(dǎo)致駕駛出了問題誰去負(fù)責(zé)？

智能座艙芯片，一個手機(jī)芯片就能搞定，不值得綁定在智能駕駛芯片上。高端L3以上的智能駕駛會犧牲功能安全性，去將就低成本的智能座艙？再說，一旦上了L3，實(shí)現(xiàn)部分自動駕駛，目前智能座艙上的大多數(shù)智能功能會失去意義，如語音手勢智能控制等

智能駕駛芯片會有接口輸出一些傳感器信息或智能處理后的信息等給座艙芯片使用，但不會讓座舵芯片來控制智能駕駛芯片，這是常識。除了功能安全外，另外信息安全也是導(dǎo)致兩者分離的原因之一。

4.2.2 軟件層面的挑戰(zhàn)

1）OTA升級策略

智能座艙和智能駕駛兩者的OTA軟件模塊、升級模塊的數(shù)據(jù)量、數(shù)據(jù)包的大小可能都不太一樣，在這樣的情況下，做好OTA的升級策略也存在一定的挑戰(zhàn)。

趙建洪認(rèn)為，艙駕融合后，座艙發(fā)布的數(shù)據(jù)包和智駕發(fā)布的數(shù)據(jù)包需要要整合在一起才能升級。因?yàn)樯婕昂芏嗟墓δ埽绾胃玫卣显谝黄饡幸欢ǖ碾y度。同時，兩者有各自的功能升級策略，有的升級頻率是三個月，有的升級頻率為半年。并且，座艙升級頻率比較高，并且座艙還經(jīng)常容易出問題，出問題就要升級，臨時更新內(nèi)容也需要馬上升級。

2）軟件上的安全隔離

SoC上面需要隔離出不同區(qū)域，并且適配好不同的操作系統(tǒng)。A核上面一般會跑 Linux或QNX系統(tǒng)；內(nèi)置MCU、M核或R核上會跑AUTOSAR CP。

汪浩偉講到：“對于艙駕融合方案，在軟件上進(jìn)行整合，并做好安全隔離，確保不同應(yīng)用的功能安全和信息安全。如此一來，座艙便不會影響自動駕駛，自動駕駛也不會影響到座艙。隔離是系統(tǒng)設(shè)計(jì)的問題，要從系統(tǒng)設(shè)計(jì)出發(fā)去考慮怎么去做隔離方案。隨著芯片的集成化程度越來越高，方案會越來越統(tǒng)一，直到有一天大家都用一種或少數(shù)幾種芯片、一種操作系統(tǒng)，并且應(yīng)用程序也非常固定的時候，功能安全方案才會固定下來。不然，功能安全方案永遠(yuǎn)是跟著項(xiàng)目走，一個項(xiàng)目可能就需要采用一種功能安全方案。

“安全級別不一樣的軟件放在一起如何共存？既要保證安全件的絕對安全性，又要保證非安全件的“人權(quán)”，—— 他們不是“奴隸”，也需要獲取一部分資源?？梢栽诓僮飨到y(tǒng)上面再嵌套操作系統(tǒng)，虛擬機(jī)是一種，也可以采用Container的方式去做。通過這些方式都可以在軟件層面上把不同的應(yīng)用隔離出來，但更大的問題在于隔離完以后該怎么辦？—— 通訊怎么解決、調(diào)度怎么解決、資源怎么保證，這些問題才是更主要的?！?/p>

目前座艙和智駕中相關(guān)模塊對功能安全的要求：座艙的中控娛樂模塊需要達(dá)到ASIL A等級，儀表模塊需要達(dá)到ASILB等級；智駕的泊車模塊至少需要達(dá)到ASILB等級，行車模塊需要達(dá)到ASILD等級。那么芯片底層的加速器資源針對這些不同功能安全等級的應(yīng)用如何進(jìn)行有效隔離也是一個比較大的挑戰(zhàn)。

楊曾舉例說：“以GPU為例，既可以用于做深度學(xué)習(xí)，又可以用于圖像渲染，但是在系統(tǒng)設(shè)計(jì)的時候，到底留多少給座艙做圖形渲染，又留多少給智駕做AI計(jì)算？GPU資源的劃分既要滿足不同功能域的需求，又要支持不同域功能安全的隔離，同時還要保證不同域的數(shù)據(jù)流能夠互相訪問復(fù)用，這不僅對芯片底層設(shè)計(jì)，甚至對整個系統(tǒng)軟件的設(shè)計(jì)，都提出了比較高的要求?！?/p>

3）虛擬機(jī)技術(shù)帶來額外的硬件開銷

艙駕融合需要在操作系統(tǒng)層面做虛擬化技術(shù)，但虛擬化技術(shù)并非解決問題的完美方案。因?yàn)椴捎锰摂M機(jī)將會占用一定的硬件資源。據(jù)業(yè)內(nèi)相關(guān)人士透露，采用虛擬機(jī)將會導(dǎo)致額外增加10%以上的CPU開銷，同時在商業(yè)層面，虛擬化也會帶來更多的授權(quán)許可成本。

“雖然虛擬化對整體資源會有一定的消耗，但是它也帶來了額外的好處 —— 實(shí)現(xiàn)了對客戶機(jī)資源靜態(tài)的劃分及分配?？蛻魴C(jī)應(yīng)用之間不互相干擾、信息不會互相串訪，保證了功能與信息安全性，簡化了上層軟件的開發(fā)，所以這些資源的耗費(fèi)也是值得的。”楊曾解釋道。

4.2.3 工程化層面的挑戰(zhàn)

1）測試驗(yàn)證層面

某主機(jī)廠自動駕駛系統(tǒng)架構(gòu)專家認(rèn)為：智能駕駛本身在進(jìn)行底層軟件以及應(yīng)用軟件集成的時候就面臨很多問題，現(xiàn)在還要和座艙的相關(guān)功能一起去進(jìn)行集成測試和回歸測試，不僅工作量很大，并且也很難保證整個產(chǎn)品的可靠性。

2）開發(fā)體系不同

“智駕系統(tǒng)和座艙系統(tǒng)本來是兩套獨(dú)立的體系，都有自己的開發(fā)節(jié)點(diǎn)和發(fā)展路線。特別是智駕系統(tǒng)，現(xiàn)在發(fā)展還不是特別成熟，比如Orin芯片，雖然現(xiàn)在蔚小理等很多家都在用，但是它的功能尚未被完全開發(fā)出來，至少需要2~3年后才能夠發(fā)揮出來。如果把兩者放在一個時間節(jié)點(diǎn)上去開發(fā)，問題會很多，不僅達(dá)不到1+1大于2的效果，甚至可能還會相互拖后腿，沒有必要過早的就交叉融合在一起。當(dāng)兩者的技術(shù)達(dá)到一定成熟度的時候，自然會有一些整車廠愿意去嘗試?！壁w建洪表示。

4.2.4 跨部門協(xié)作難

艙駕融合還面臨另外一個難題，就是“部門墻”的問題。業(yè)內(nèi)相關(guān)專家大都認(rèn)為，如果要把座艙和智駕的功能集成到一個SOC芯片上來，確實(shí)對主機(jī)廠的組織架構(gòu)存在挑戰(zhàn)，根本原因在于誰來做、誰承擔(dān)責(zé)任的問題。最終整合的話，相當(dāng)于把這些研發(fā)資源都打通了，一起來管理。如果還是現(xiàn)在這種跨部門協(xié)作，肯定多少會存在扯皮、懈怠的問題，難以保證開發(fā)效率和質(zhì)量。

4.2.5 缺乏統(tǒng)一的行業(yè)標(biāo)準(zhǔn)

汪浩偉談到：“實(shí)現(xiàn)真正的艙駕融合，首先要讓座艙和智駕把自己的整個架構(gòu)打開，打開以后把各自的服務(wù)做好。SOA實(shí)現(xiàn)路徑中間必經(jīng)的一步就是要把原來單體的軟硬件架構(gòu)打碎，變成一個個微服務(wù)。這一步做完之后，再談如何去做融合，不僅智艙和智駕兩個部門協(xié)作的難度會降低不少，而且后期在資源和時間上的投入也會少很多。

“但是這個事情，需要行業(yè)標(biāo)準(zhǔn)的推動，甚至需要強(qiáng)迫一些廠商逐漸把它的軟件架構(gòu)打開。制定行業(yè)標(biāo)準(zhǔn)的目的就是把大家的利益統(tǒng)一起來，誰不跟著行業(yè)標(biāo)準(zhǔn)走，誰就會吃虧、掉隊(duì)，甚至面臨淘汰，這樣才能逐漸推動整個行業(yè)的發(fā)展和進(jìn)步。”

5. 艙駕融合對開發(fā)模式和產(chǎn)業(yè)鏈格局的影響

5.1 對開發(fā)模式的影響

從開發(fā)模式上來說，在艙駕融合之前，造車新勢力也好、傳統(tǒng)主機(jī)廠也罷，他們的智能座艙和智能駕駛，是分別開發(fā)、再拉通的模式，基本上是智艙部門承接智駕部門的需求，把智駕相關(guān)的顯示、操控需求，簡單地加入到座艙開發(fā)中，可以想象得到，其融合程度一定是很低的。

而秉承艙駕融合的理念，智艙與智駕的開發(fā)需要同步進(jìn)行，從一開始兩者就緊密相連，智駕部門會將座艙、人機(jī)交互等內(nèi)容，也作為智能駕駛的一部分來考慮；智艙部門也會將智駕功能在車內(nèi)的表現(xiàn)，作為重中之重來考慮。

那么未來會主機(jī)廠的智艙和智駕部門的組織架構(gòu)又將會是怎樣的一種形態(tài)，誰又會去融合誰？

當(dāng)前，在主機(jī)廠的研發(fā)部門，智駕和座艙是兩個獨(dú)立的部門。智駕內(nèi)部又分行車和泊車兩個不同的團(tuán)隊(duì)，再往下可能會分多個不同專業(yè)——感知、規(guī)控、定位等專業(yè)小組；座艙部門會分為HUD、儀表和中控等不同團(tuán)隊(duì)。另外，還有專門負(fù)責(zé)車型的部門，車型部門會圍繞車型的EE架構(gòu)以及系統(tǒng)的一些技術(shù)，包括需求定義等開展工作。當(dāng)車型的功能定義好之后，車型部門相關(guān)負(fù)責(zé)人會找具體的部門來協(xié)作。整體來說，一般是由車型部門的項(xiàng)目經(jīng)理或項(xiàng)目總監(jiān)來整合這兩部分的需求，這是目前智艙和智駕兩個部門比較常見的一種開發(fā)合作模式。

智艙和智駕進(jìn)行融合，到底哪個部門或者團(tuán)隊(duì)主導(dǎo)牽頭去做這件事情，應(yīng)該也是分階段的。在現(xiàn)階段，座艙和泊車進(jìn)行融合，泊車功能比較成熟，座艙功能要比泊車功能復(fù)雜，并且座艙團(tuán)隊(duì)也比較龐大，這個時候適合座艙團(tuán)隊(duì)做主導(dǎo)。到后期，隨著智駕技術(shù)發(fā)展成熟，以及智駕團(tuán)隊(duì)不斷地發(fā)展壯大，多半是以智駕部門為主導(dǎo)去融合座艙，畢竟智駕的復(fù)雜度和對安全的重視程度要高于座艙。

未來艙駕融合之后，主機(jī)廠的組織架構(gòu)會受到哪些影響？趙建洪認(rèn)為：不管最終兩個部門是否合并成一個部門，智艙和智駕始終都會是兩個獨(dú)立的團(tuán)隊(duì)，畢竟他們專業(yè)分工不同，兩個部門都非常重要，把哪個部門做降級處理都不太現(xiàn)實(shí)。但是很有可能會出現(xiàn)一些主機(jī)廠把智駕和智艙合并成一個智能化部門 —— 我中有你，你中有我，從一開始就奠定了艙駕深度融合的基礎(chǔ)。

5.2 對產(chǎn)業(yè)鏈格局的影響

整車EE架構(gòu)從分布式向集中式域控架構(gòu)轉(zhuǎn)變的過程中，產(chǎn)業(yè)鏈從Tier2→Tier1→OEM這種線性關(guān)系，逐漸演變成以主機(jī)廠為中心的網(wǎng)狀關(guān)系。那么到跨域融合的階段，是否會對現(xiàn)在的產(chǎn)業(yè)鏈格局有更進(jìn)一步的影響？

從集中式域控到跨域融合，產(chǎn)業(yè)鏈格局其實(shí)還是網(wǎng)狀的。只不過這種格局需要主機(jī)廠的掌控力更強(qiáng)，對主機(jī)廠的要求更高。

楊曾談到：“通常情況下，主機(jī)廠智駕域控的硬件和底層軟件基本上會定一個供應(yīng)商，功能模塊可能會再找另外一家供應(yīng)商，然后主機(jī)廠參與去做基礎(chǔ)軟件和整個域控系統(tǒng)的集成，這是一種在智駕場景下的合作方式，這種合作方式也會拓展到艙駕融合的控制器。

“如果主機(jī)廠做艙駕融合方案，首先會找一家做底層硬件和基礎(chǔ)軟件的Tier1供應(yīng)商，它需要至少對一家主流芯片公司的芯片及其Roadmap比較熟悉。其次，再由主機(jī)廠牽頭，去找一些中間件的模塊，比如說智駕相關(guān)安全集成的中間件模塊。再次，主機(jī)廠一般會找一些之前合作比較好或者能力比較強(qiáng)的智駕或座艙方面的公司，提供一些應(yīng)用算法模塊。最后，主機(jī)廠把所有功能進(jìn)行集成，并統(tǒng)一牽頭做系統(tǒng)驗(yàn)證和測試?！?/p>

對于域控供應(yīng)商而言，之前所謂的Tier1和Tier2之間的分工和定位越來越模糊。

曹晶認(rèn)為：“Tier1和Tier2的界限逐漸模糊，并且出現(xiàn)了Tier 0.5和Tier1.5。我們做域控設(shè)計(jì)的公司，對于輕量級的智駕域控，客戶需要把所有功能都做一個整合，由于此類域控軟件的代碼量不高，我們自己就可以把這些功能全部完成。但是，對于比較復(fù)雜的的大算力域控，所有的軟硬件模塊都有一家Tier1來做也不太現(xiàn)實(shí)，如果市面上有一些已經(jīng)量產(chǎn)的、比較好用的模塊，比如感知模塊，我們會直接去做集成，以提高研發(fā)周期降低自研成本。在這些情況下，我們基本就是在扮演一個Tier1的角色。

“在艙駕融合的階段，主機(jī)廠大多會采用SOA的架構(gòu)，要求軟硬件做更好的解耦，因?yàn)檐浖切枰粩嗟豋TA升級，從原來的買一個功能到后面就變成買一個服務(wù)，那個時候就會跟供應(yīng)商綁定得比較深，需要供應(yīng)商去維護(hù)這套軟件框架，在未來幾年的生命周期內(nèi)也要不斷地去迭代，這種情況下域控制器供應(yīng)商就更像是一個Tier0.5的角色?！?/p>

智能汽車的產(chǎn)業(yè)鏈格局會隨著整車架構(gòu)的變化而變化，原先的產(chǎn)業(yè)格局屬于垂直整合和橫向分割，隨著EE架構(gòu)由分布式走向域集中式，產(chǎn)業(yè)鏈格局逐漸變成水平整合和垂直分割。

水平整合 —— 現(xiàn)在車上控制器越來越少，座艙和智駕甚至也要合并成一個艙駕一體域控制器，最后甚至還要把網(wǎng)關(guān)、BCM、VCM統(tǒng)統(tǒng)整合進(jìn)來，集成為一個中央計(jì)算平臺。

垂直分割 —— 硬件（包括芯片）、底層軟件和應(yīng)用層軟件會由不同的公司分工去完成。每個公司專精于被垂直分割的一個垂直技術(shù)領(lǐng)域。

“艙駕一體作為中央計(jì)算平臺發(fā)展的一個過渡形態(tài)，會推動整個汽車產(chǎn)業(yè)徹底走向軟硬分離的方式。然后大家在垂直方向去尋找自己擅長的領(lǐng)域—— 有人專門設(shè)計(jì)芯片，有人專門設(shè)計(jì)底層軟件，也有人專門設(shè)計(jì)應(yīng)用層軟件，甚至還有人專門做硬件代工。”汪浩偉解釋道。

審核編輯 ：李倩