引言：

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

那么，什么是艙駕融合？目前企業(yè)在艙駕融合上在做怎樣的探索？艙駕融合方案的優(yōu)勢(shì)和面臨的挑戰(zhàn)是什么？艙駕融合對(duì)開(kāi)發(fā)模式和產(chǎn)業(yè)鏈格局又會(huì)帶來(lái)什么樣的影響？帶著這些問(wèn)題，筆者訪談了相關(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)典五域：座艙域、智駕域、動(dòng)力域、底盤(pán)域、車身域。再往后發(fā)展，到域融合階段，五大功能域之間開(kāi)始嘗試進(jìn)行跨域融合，雖然不同的主機(jī)廠有不同的理解和做法，但大體思路是一致的，即先將部分域的功能集成到一個(gè)高性能計(jì)算單元內(nèi)，再逐漸聚合更多的功能域，最終實(shí)現(xiàn)1個(gè)中央計(jì)算大腦的目標(biāo)。艙駕融合差不多就是在這個(gè)階段誕生的產(chǎn)物—— 座艙域和智能駕駛域進(jìn)行跨域融合，形成艙駕一體域控制器。

不同形式的跨域融合嘗試 （信息來(lái)源：公開(kāi)資料整理）

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

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

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

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

1.1 艙駕融合層級(jí)的劃分

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B. L4級(jí) - 軟硬件均開(kāi)始融合

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

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

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

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

2.1 特斯拉艙駕融合方案簡(jiǎn)介

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

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

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

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

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

在軟件層面：

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

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

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

1）更高效的通訊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 Tier1

1）德賽西威

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

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

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

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

2）創(chuàng)時(shí)智駕

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

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

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

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

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

2022年初，發(fā)布基于高通SA8295芯片的硬件平臺(tái)，實(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)用層級(jí)的融合 —— SR智能輔助駕駛環(huán)境模擬

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

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

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

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

艙駕一體域控制器示意圖 （圖片來(lái)源：小鵬公開(kāi)宣講材料）

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

2）上汽零束

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

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

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

3）集度汽車

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

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

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

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

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

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

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

4.1 單SoC芯片方案帶來(lái)的好處

1） 成本可以做得更低

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

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

2）通訊時(shí)延更短

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

3）OTA升級(jí)空間更大

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

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

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

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

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

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

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

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

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

2）硬件資源分配

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

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

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

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

3）行駛安全考慮

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

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

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

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

1）OTA升級(jí)策略

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

趙建洪認(rèn)為，艙駕融合后，座艙發(fā)布的數(shù)據(jù)包和智駕發(fā)布的數(shù)據(jù)包需要要整合在一起才能升級(jí)。因?yàn)樯婕昂芏嗟墓δ?，如何更好地整合在一起?huì)有一定的難度。同時(shí)，兩者有各自的功能升級(jí)策略，有的升級(jí)頻率是三個(gè)月，有的升級(jí)頻率為半年。并且，座艙升級(jí)頻率比較高，并且座艙還經(jīng)常容易出問(wèn)題，出問(wèn)題就要升級(jí)，臨時(shí)更新內(nèi)容也需要馬上升級(jí)。

2）軟件上的安全隔離

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.4 跨部門(mén)協(xié)作難

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

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

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

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

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

5.1 對(duì)開(kāi)發(fā)模式的影響

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“艙駕一體作為中央計(jì)算平臺(tái)發(fā)展的一個(gè)過(guò)渡形態(tài)，會(huì)推動(dòng)整個(gè)汽車產(chǎn)業(yè)徹底走向軟硬分離的方式。然后大家在垂直方向去尋找自己擅長(zhǎng)的領(lǐng)域—— 有人專門(mén)設(shè)計(jì)芯片，有人專門(mén)設(shè)計(jì)底層軟件，也有人專門(mén)設(shè)計(jì)應(yīng)用層軟件，甚至還有人專門(mén)做硬件代工?！蓖艉苽ソ忉尩?。

審核編輯 ：李倩