引言：

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

那么，什么是艙駕融合？目前企業在艙駕融合上在做怎樣的探索？艙駕融合方案的優勢和面臨的挑戰是什么？艙駕融合對開發模式和產業鏈格局又會帶來什么樣的影響？帶著這些問題，筆者訪談了相關領域的技術專家，希望能夠對“艙駕融合”有更深層次的理解。

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

眾所周知，汽車的智能化程度取決于底層的EE架構。在汽車智能化的進程中，EE架構的發展路線從功能獨立的分布式架構，到功能集成的域集中式架構，最后再到高度集成的中央計算＋區域控制的中央集中式架構。

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

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

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

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

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

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

1.1 艙駕融合層級的劃分

1）應用層面的融合

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

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

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

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

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

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

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

目前，有一些芯片公司和主機廠在探討這樣的方案，未來也很有可能會有這樣的一些芯片產品出現。但是，理想很豐滿，現實很骨感，短期內應該是很難看到這樣的理想方案落地。

據業內專家透露，大部分車型無論是對于成本，還是可靠性都比較敏感。同樣，開發一個新車型，車型的上市周期也會有一定的要求，所以主機廠一般會首選技術成熟度較高，并且成本已經在行業內能夠被分攤下來的成熟方案。另外，不管是主機廠的組織架構，還是對應用層的梳理，都需要很長時間去調整和消化。因此，這樣的產品需求不會一下子就爆發出來。

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

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

映馳科技產品副總裁趙建洪講到：“我們首推的是艙泊融合方案，并且，主機廠對艙泊融合也有一定的需求。因為泊車方案現在比較成熟，同時，座艙域控制器上的算力也有了一定的富余，把泊車功能融合到座艙域控制器具有一定的成本優勢。不過，艙泊融合相當于是艙駕融合的第一步，由于行車方案目前還不是很成熟，需要兩者都發展成熟的時候，再去考慮融合的問題。”

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

為什么依然有企業有動力去做兩者的融合？因為在應用層面上，兩者之間可以互相借力。之所以現在艙駕融合的應用價值還沒有被完全挖掘出來，是因為底層的軟件設計還沒達到相應的程度，需要將底層的邏輯進行封裝，比如，做成一個個微服務的形式。在這樣的情況下，座艙和智駕之間就可以更容易地去相互調用對方的服務或者資源，進而就能夠比較容易地去開發新的融合應用。”

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

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

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

1）觀點1 ：只有在L3級及以下融合才有意義

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

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

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

A. L3及以下 - 硬件獨立，上層應用融合

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

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

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

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

當自動駕駛發展到L4級，即無人駕駛階段，人從駕駛任務中解放出來，汽車本身成為服務的載體，座艙的設計思路將從以駕駛員為核心轉向以乘客為核心。那么，座艙和智駕之間的融合應用也將從提供輔助駕駛相關的信息為主，轉變為以提供生活服務相關的信息為主。在這個階段，儀表或者HUD上便不再需要顯示一些駕駛員接管的提醒或其它一些用于輔助駕駛的圖像信息（比如用于泊車的360全景信息顯示），更多地會展示一些娛樂和工作相關信息（比如，基于車外的攝像頭數據在艙內展示一些車外的風景信息等）。

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

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

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

中央計算平臺（CCM）的硬件構成（參考2021款ModelS）：

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

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

C. 車內外通信系統控制單元的主控芯片：高通SA415M

特斯拉中央計算模塊CCM內部電路板組構成 （圖片來源：UBS Evidence Lab）

在軟件層面：

A.信息娛樂控制單元采用自研的車機操作系統，它基于開源的 Linux 操作系統進行定制開發。

B.駕駛輔助系統控制單元上的MCU運行FreeRTOS，SoC上采用基于Linux進行深度定制開發的Version操作系統。

2.2 特斯拉艙駕融合方案的優勢

1）更高效的通訊

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

2）共用一套散熱系統，節省成本

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

3）節省空間，易于布置

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

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

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

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

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

特斯拉這種把座艙和智駕模塊放在一個盒子里面，從表面上看，感覺技術難度也不大，為什么到現在依然很少有其它主機廠去效仿特斯拉，是否存在一些技術壁壘和局限性，導致沒有實力的主機廠想模仿卻模仿不了，而有實力的主機廠因為其中的局限性而選擇了去規劃其它方案？

2.3.1 特斯拉艙駕融合方案的技術壁壘

1）電磁干擾設計有難度

特斯拉的CCM模塊內，因為不同板子之間都是高速信號在傳輸，板子之間會存在電磁互相干擾的潛在問題，怎樣消除不同板子之間的電磁干擾會存在一定的難度。

2）需要對整個系統架構有很深的理解

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

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

1）不適合平臺化應用

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

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

2）不具備較強的擴展性

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

創時智駕首席產品專家楊曾提到：“如果考慮擴展性，軟件還可以通過OTA更新來實現，但是艙駕融合域控制器硬件的可擴展性如何實現？如果前期能夠為座艙和智駕預留足夠多的接口和算力資源，那么后期也許還可以逐漸增加新的功能。但現實是，座艙和智能駕駛技術都還處于不斷地發展中，尤其是智能駕駛，迭代速度更快，前期很難把規劃做得完美無缺，若后期再改動，其設計和平臺驗證都需要很多的時間和資源投入。”

3. 國內企業艙駕融合方案的探索

3.1 Tier1

1）德賽西威

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

2022年4月，發布車載智能計算平臺“Aurora”—— 實現從了從域控制器向中央計算平臺的跨越。

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

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

2）創時智駕

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

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

創時智駕域控制器產品規劃 （圖片來源：創時智駕公開宣講材料）

3）中科創達

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

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

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

基于高通SA8795芯片（預計，CPU算力240K DMIPS、 NPU算力60 TOPS）布局座艙和智能駕駛的跨域融合方案，并計劃于2024年實現量產。

3.2 主機廠

1）小鵬

A 。 應用層級的融合 —— SR智能輔助駕駛環境模擬

該技術是基于高德第三代車載導航實現的。在技術方案上，將導航與高精地圖深度融合，并將智駕系統的感知、決策信息與車道級導航更加精準地匹配。

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

小鵬SR系統 （圖片來源：小鵬汽車獲2022年度德國iF設計三項用戶體驗大獎 （baidu.com））

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

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

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

2）上汽零束

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

在上汽零束的全棧3.0架構中，硬件平臺方面由兩個HPC高性能計算單元HPC1和HPC2以及四個區域控制器（ZONE）構成。其中一個HPC高性能計算單元融合了座艙和智駕功能。在軟件層面，通過中間件和SOA原子服務層，使得向上能夠提供統一、標準的API接口，能夠讓應用層開發更輕松，復用性更高。

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

3）集度汽車

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

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

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

B. 3D人機共駕地圖

集度在座艙內基于現實環境通過仿真建模為駕駛員構建了一個虛擬的駕駛世界，實現靜態地圖導航和動態感知數據融合，打通虛擬場景與現實交通環境的障礙。從集度發布的視頻來看，通過智能座艙和智能駕駛系統之間的跨域資源調度，智能駕駛系統感知到的障礙物模型支持直接可視化融合顯示在 3D 地圖上，提供了還原現實的虛擬化駕駛體驗。

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

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

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

1） 成本可以做得更低

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

部分底層軟件可以共用，可以節約一部分底層軟件的開發成本或購買成本。

2）通訊時延更短

相比于之前通過網絡總線傳輸的方式或兩個板子件通過Switch通訊，現在可以使用內存共享的方式，通訊時延會更短。

3）OTA升級空間更大

某主機廠自動駕駛系統架構專家認為：“艙駕融合后，數據信息可以共享，兩者之間的交互可以做得更多，軟件迭代的想象空間會更大。如果兩個域還是完全獨立，接口基本上是固定的，接口變，雙方軟件就要跟著變，比如在后期，一些主機廠會要求增加一個新功能，就需要訂閱一些服務，會發現訂閱不了，因為之前的接口是定義“死”的，除非在開始的時候就能夠把接口定義得特別豐富，否則，一旦后期需要做變更，就需要跨部門提變更需求，再次跨部門進行協作，溝通成本很高。如果兩者融合了，再增加新的功能，一般只需要對軟件模塊做一些變更，不再需要變更硬件接口，便于在后期做一些系統上的OTA升級。”

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

4.2 單SoC芯片方案面臨的挑戰

4.2.1 硬件層面的挑戰

1）芯片本身的設計

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

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

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

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

2）硬件資源分配

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

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

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

“智能座艙和智能駕駛功能集成在單顆SoC芯片上的時候，因為兩個域的需求完全不同，在做硬件資源分配的時候，既要定義這些應用的優先級，又要確保這些應用有足夠資源可以用 —— 能夠保證互相不打架，也不能出現一個應用鎖死另外一個應用的現象。”汪浩偉表示。

3）行駛安全考慮

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

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

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

4.2.2 軟件層面的挑戰

1）OTA升級策略

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

趙建洪認為，艙駕融合后，座艙發布的數據包和智駕發布的數據包需要要整合在一起才能升級。因為涉及很多的功能，如何更好地整合在一起會有一定的難度。同時，兩者有各自的功能升級策略，有的升級頻率是三個月，有的升級頻率為半年。并且，座艙升級頻率比較高，并且座艙還經常容易出問題，出問題就要升級，臨時更新內容也需要馬上升級。

2）軟件上的安全隔離

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

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

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

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

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

3）虛擬機技術帶來額外的硬件開銷

艙駕融合需要在操作系統層面做虛擬化技術，但虛擬化技術并非解決問題的完美方案。因為采用虛擬機將會占用一定的硬件資源。據業內相關人士透露，采用虛擬機將會導致額外增加10%以上的CPU開銷，同時在商業層面，虛擬化也會帶來更多的授權許可成本。

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

4.2.3 工程化層面的挑戰

1）測試驗證層面

某主機廠自動駕駛系統架構專家認為：智能駕駛本身在進行底層軟件以及應用軟件集成的時候就面臨很多問題，現在還要和座艙的相關功能一起去進行集成測試和回歸測試，不僅工作量很大，并且也很難保證整個產品的可靠性。

2）開發體系不同

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

4.2.4 跨部門協作難

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

4.2.5 缺乏統一的行業標準

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

“但是這個事情，需要行業標準的推動，甚至需要強迫一些廠商逐漸把它的軟件架構打開。制定行業標準的目的就是把大家的利益統一起來，誰不跟著行業標準走，誰就會吃虧、掉隊，甚至面臨淘汰，這樣才能逐漸推動整個行業的發展和進步。”

5. 艙駕融合對開發模式和產業鏈格局的影響

5.1 對開發模式的影響

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

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

那么未來會主機廠的智艙和智駕部門的組織架構又將會是怎樣的一種形態，誰又會去融合誰？

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

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

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

5.2 對產業鏈格局的影響

整車EE架構從分布式向集中式域控架構轉變的過程中，產業鏈從Tier2→Tier1→OEM這種線性關系，逐漸演變成以主機廠為中心的網狀關系。那么到跨域融合的階段，是否會對現在的產業鏈格局有更進一步的影響？

從集中式域控到跨域融合，產業鏈格局其實還是網狀的。只不過這種格局需要主機廠的掌控力更強，對主機廠的要求更高。

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

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

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

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

“在艙駕融合的階段，主機廠大多會采用SOA的架構，要求軟硬件做更好的解耦，因為軟件是需要不斷地OTA升級，從原來的買一個功能到后面就變成買一個服務，那個時候就會跟供應商綁定得比較深，需要供應商去維護這套軟件框架，在未來幾年的生命周期內也要不斷地去迭代，這種情況下域控制器供應商就更像是一個Tier0.5的角色。”

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

水平整合 —— 現在車上控制器越來越少，座艙和智駕甚至也要合并成一個艙駕一體域控制器，最后甚至還要把網關、BCM、VCM統統整合進來，集成為一個中央計算平臺。

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

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

審核編輯 ：李倩