一、產業發展現狀

1.1 國外整體產業發展現狀

什么是電子電氣架構？在2007年由德爾福(DELPHI)首先提出E/E架構的概念，具體就是在功能需求、法規和設計要求等特定約束下，把汽車里的傳感器、中央處理器、電子電氣分配系統、軟件硬件通過技術手段整合在一起；通過這種結構，將動力總成、傳動系統、信息娛樂系統等信息轉化為實際的電源分配的物理布局、信號網絡、數據網絡、診斷、電源管理等電子電氣解決方案。

關于汽車電子電氣架構演進， 行業內討論最多的是博世提出的電子電氣架構發展六階段，如下圖所示。博世將整車 EEA 劃分為六個階段：模塊化（Modular） 、 集成化（Integration）、域集中（Domain Centralization） 、 域融合（Domain Fusion） 、 整車中央計算平臺（VehicleComputer） 、 車-云計算（Vehicle Cloud Computing）階段。該演進概念清晰指明了未來汽車電子電氣架構算力會逐漸集中化， 最終會發展到云端計算。當前主流架構處于功能域控制器集中階段， 正在朝多域控制器融合架構方向發展。

博世 EEA 發展六階段

為了適應市場對電動化的需求， 實現從分布式向集中式電子電氣架構轉變。國內外整車企業已開始建立適合未來的車輛電子電氣架構和汽車軟件架構， 使其可以在不同的車輛計劃、開發單位和組織之間進行協調， 從而提高開發的靈活性和創新性， 減少開發時間與風險。國外整車企業如特斯拉和大眾已實現整車集成至 4 個主控 ECU， 實現整車域控制器軟件開發，實現軟硬件解耦設計， 并多次通過 OTA 升級整車功能。

特斯拉 Model S、 Model X 再到 Model 3 /Y 的電子電氣架構演變， 推動力是商業模式及技術路徑的變革， 充分體現了軟件定義車輛的技術創新。

目前最有名的是特斯拉 Model 3 采用的架構， 如上圖。Model 3 車載中央電腦和區域控制器架構， 采用 Autopilot（自動駕駛） +IVI（信息娛樂系統） +T-BOX（遠程信息處理器）三合一計算平臺， 將三塊控制板集成到同一殼體中， 新引入 BCM-F/L/R 三個區域控制器， 實現 ECU 整合并對執行器供電。徹底拋棄了功能域的概念， 實現集中式電子電氣架構和區域控制器方案， 通過中央計算模塊（CCM） 對不同的區域 ECU 及其部件進行統一管理，并通過CAN（（控制器局域網） ） 進行通信， 并實現了高度集成， 高度模塊化， 對傳統汽車電子架構進行了全方位的創新， 實現了“軟件定義汽車”， 加快了汽車產品迭代速度。實現了算力集中化、 服務附加值提升、 內部拓撲結構簡化。特斯拉的準中央計算 EEA 已帶來了線束革命，Model S/Model X 整車線束的長度是 3 公里， Model 3 整車線束的長度縮短到了1.5 公里， ModelY 進一步縮短到 1 公里左右。

特斯拉的集中控制功能集成在三個域控制器中， 中央計算模塊直接整合了智能駕駛與信息娛樂域控制模塊， 以及外部連接和車內通信系統域功能， 架構方案較之前車型簡化， 即：AICM（智能駕駛與信息娛樂域控制模塊）：連接各類自動駕駛傳感器， 綜合執行邏輯計算功能， 以及完成人機交互；FBCM（前車身控制模塊） /智能配電模塊：負責 12V 的電池、 電源分配和熱管理的功能；LBCM（左車身控制模塊） 和 RBCM（右車身控制模塊）：分別負責剩下的車身與便利系統、 底盤與安全系統和部分動力系統的功能。

大眾為了適應市場對電動化的需求， 推出了 MEB 平臺， 實現從分布式向域融合電子電氣架構轉變。MEB 電子電氣架構分為整車控制器（ICAS1） 、 智能駕駛（ICAS2） 和智能座艙（ICAS3） 三大域控制器。ICAS1 實現整車所有控制類功能集成， 如高壓能量管理、 低壓電源管理、 扭矩控制、 車身電子控制、 網關、 存儲等功能；另外 ICAS1 連接診斷接口和 T-BOX，實現信息安全設計， 并作為 OTA 主控 ECU 實現整車并行刷寫。ICAS2 作為智能駕駛運算中心， 通過以太網接收 ICAS1 的雷達和攝像頭信息， 實現運算處理， 并實現對于制動和轉向系統的請求。ICAS3 采用一機多屏控制方式， 通過以太網接收 ICAS1 和 ICAS2 的需求。另外大眾推出自身 VW.OS， 并采用 Adaptive AUTOSAR（又稱 AUTOSAR AP， AUTOSAR 自適應平臺） 和 SOA 實現不同應用的集成。

沃爾沃的區域電子電氣架構包括 Core System（核心系統） 和 Mechatronic Rim（機電區域） ， 如下圖 所示。沃爾沃的 VIU（Vehicle Integration Unit， 整車集成單元） 對應不同整車區域的感知、 控制與執行。沃爾沃的 VCU（Vehicle Computation Unit， 整車計算單元/整車控制器） 對應車載中央計算機， 提供整車智能化所需的算力與數據存儲。

沃爾沃 EEA 架構示意圖

奧迪將采取中央集群計算方案（Central Computing Cluster ） 。 如下圖所示， 整車劃分為： 驅動域、 能源域、 橫縱向控制域、 駕駛輔助域、 座艙域、 車身舒適域、 信息安全域；不同的域之間通過高速以太網來進行信息交互， 域內采用 CANLIN 等進行實時低速通信；新架構分為傳感器與執行器層和承載不同功能的域層； 車輛的中央計算單元會與企業的后臺相連接， 奧迪的后臺會與 HERE 后臺相連， 接進行數據共享。

奧迪 EEA 架構示意圖

1.2 國內整體產業發展現狀

目前， 國內主流汽車企業三化融合車型的電子電氣架構方案已從完全分布式控制， 進入域集中式控制。 國內造車新勢力普遍直接采用功能域控到域融合的過渡方案， 域融合方案普遍集中在智能駕駛和智能座艙。

1.2.1 小鵬汽車G9電子電氣架構具領先性

勢力三強中小鵬汽車在電子電氣架構方面走得比較領先，隨著車型從 G3、P7和P5，迭代到 G9 的這套X-EEA3.0電子電氣架構，已經進入到中央集中式電子電氣架構。憑借領先一代的架構，搭載更高算力SOC芯片及更高算力利用率，小鵬G9或成首款支持 XPILOT 4.0 智能輔助駕駛系統的量產車。

小鵬P7搭載小鵬第二代電子電氣架構，具備混合式的特點：

• 分層域控——功能域控制器（ 智駕域控制器、車身域控制器、動力域控制器等模塊）與中央域控制器并存；

• 跨域整合——域控制器覆蓋多重功能，保留局部的傳統 ECU；

• 混合設計——傳統的信號交互和服務交互成為并存設計。

因此 CAN 總線和以太網總線并存，大數據/實時性交互均得以保證；以太網節點少，對網關要求低。

因此CAN總線和以太網總線并存，大數據/實時性交互均得以保證；以太網節點少，對網關要求低。小鵬第二代電子電氣架構實現傳統ECU數量減少約60%，硬件資源實現高度集成，大部分的車身功能遷移至域控制器，中央處理器可實現支持儀表、信息娛樂系統以及智能車身相關控制的大部分功能，同時集成中央網關，兼容 V2X 的協議，支持車與車的局域網的通信，支持車與云端的互聯，車與遠程數字終端的連接功能。小鵬汽車的智能駕駛域控制器，集成了高速NGP、城市GNP及泊車功能。小鵬輔助駕駛采用激光雷達視覺融合方案，與特斯拉的純視覺方案不同，這就導致兩者硬件架構不同，對于通訊帶寬、計算能力的要求也不一樣。

小鵬汽車電子電氣架構演進歷史

小鵬汽車將其X-EEA3.0電子電氣架構稱為“讓智能汽車在未來永不落伍的秘密”。根據公司披露的首搭于 G9的電子電氣架構的信息，未來 G9可以升級和優化的潛力較大。

X-EEA 3.0硬件架構方面，采用中央超算（C-DCU）+區域控制（Z-DCU）的硬件架構，中央超算包含車控、智駕、座艙3個域控制器，區域控制器為左右域控制器，將更多控制件分區，根據就近配置的原則，分區接管相應功能，大幅縮減線束。

得益于小鵬汽車的全棧自研能力，新架構做到了硬件和軟件的深度集成，不僅實現軟硬件解耦，也實現軟件分層解耦，可使得系統軟件平臺、基礎軟件平臺、智能應用平臺分層迭代，把車輛的底層軟件和基礎軟件與智能、科技、性能相關的應用軟件脫離開，在開發新功能時，只需要對最上層的應用軟件進行研究和迭代就可以，縮短了研發周期和技術壁壘， 用戶也能夠享受到車的快速迭代。

• 系統軟件平臺：基于外購代碼做部分定制開發，隨整車基礎軟件平臺凍結而凍結， 可復用于不同車型；

• 基礎軟件平臺：多個整車基礎功能軟件均形成標準服務接口且在車輛量產前凍結， 可復用于不同車型；

• 智能應用平臺：如自動駕駛、智能語音控制、智能場景等功能，可實現快速開發和迭代。

X-EEA 3.0 數據架構方面，域控制器設置內存分區，升級運行互不干涉，便用車邊升級，30分鐘可升級完成。

通信架構方面， X-EEA3.0 在國內首次實現了以千兆以太網為主干的通信架構，同時支持多通訊協議，讓車輛在數據傳輸方面更快速。從G9 搭載的新一代電子電氣架構可以看出，小鵬在骨干網絡的建設和面向 SOA 的方向起步較早。

X-EEA 3.0 電力架構方面， 可實現場景式精準配電，可根據駕駛、第三空間等不同用車場景按需配電，比如在路邊等人時，可以只對空調、座椅調節、音樂等功能供電，其他部分斷電，這樣就能實現節能耗節省，提高續航里程。車輛定期自診斷，主動發現問題，引導維修，以科技手段賦能售后。

小鵬汽車第三代電子電氣架構實現千兆以太網+中央計算+區域控制

1.2.2 極氪001汽車電子電氣架構

極氪汽車已量產（車型：極氪 001） 的電子電氣架構是功能域集中式架構 ，由四大功能域主控承擔整車級別的各域功能邏輯軟件部署中心的角色， 將絕大多數傳感器和執行器的控制邏輯與整車功能應用進行分離， 大部分普通 ECU 作為純粹的傳感和執行控制單元， 功能域內跨子系統和子系統內部的邏輯接口交互在域控內部即可完成， 跨域信息交互通過 Flexray（高速容錯網絡協議） 和以太網為主干網的雙網實現。ECU 實現功能業務應用和執行器控制邏輯的解耦， 功能接口模塊化、 標準化、 開放化。在電子硬件集成度上， 域控集成了大量的簡單 I/O 驅動 ，復雜的執行器和傳感器作為獨立的電子單元通過CAN/LIN/A2B/LVDS 等網絡連接在各自的域控上， 一定程度上縮減了 ECU 數量、 降低了整車成本。

極氪汽車 EEA 架構示意圖

1.2.3 華為CCA架構

華為基于自身的 ICT 技術為積累， 推出華為 CCA 架構為基礎的全棧式解決方案 。其中底層的基礎是“計算+通信”為核心的 CCA 架構， 用以太環網作為車載通信主干網絡， 實現了“功能域”+“區域”的集成。以太環網+VIU 區域控制器構建車內通信架構。整車網絡架構設置 3-5 個 VIU， 相應的傳感器、 執行器甚至部分 ECU 就近接入， 實現電源供給、 電子保險絲、 I/O 口隔離等功能。VIU 之間通過高速以太網的環形網絡進行連接， 確保整車網絡高效率和高可靠。在整車通信架構之上， 設置智能座艙域控制器 CDC、 智能駕駛域控制器 MDC 和整車控制VDC， 共同完成信息娛樂、 自動駕駛、 整車及底盤域的控制。

1.3 國內外架構整體方案對比

總體而言， 國內整車企業電子電氣架構整體方案與國外傳統整車企業方案相當， 都處在功能域控或功能域控到域融合的過渡階段。 不過， 國內方案相對比在行業內處于領先地位的特斯拉架構方案， 大概有 3~5 年的的差距，這些差距主要體現在：

a. 功能軟件設計模型方面， 國內整車企業自主設計車載核心功能較少， 缺少開發和驗證能力積累。

b. 架構設計的模型庫方面， 尤其是在智能駕駛功能方面， 國外主流整車企業在開發智能駕駛功能時均基于較為完善的功能模型庫進行設計和驗證， 以確保智能駕駛的可靠性和安全性。而國內各整車企業在智能駕駛功能模型的開發領域還處于空白階段， 大部分需要依靠國外供應商或者第三方技術支持才能開展智能駕駛設計工作。另外， 智能駕駛的場景數據庫也是目前國內整車企業的儲備軟肋。

c. 控制器底層軟件方面， 市場底層軟件多為國外產品， 我國產品的應用范圍少、 用量少， 很難發展完善；

d. 主流車載總線技術方面， 技術被國外壟斷， 難以滿足國內智能網聯汽車在通信方面需求；

e. 汽車電子基礎軟件方面， 國外汽車行業已較成熟（日本汽車軟件標準化組織 JASPAR和歐洲 AUTOSAR 體系） ， 而國內屬于發展初期。另外， 汽車電子底層軟件主要依賴國外零部件供應商。

f. 網絡架構設計方面， 智能網聯汽車的通信網絡需要滿足大帶寬、 高實時性的要求，車載以太網作為車載網絡中的主干網是新型網絡架構的必然趨勢。國際上基于車載以太網的新型網絡拓撲結構以及通信協議已經基本成型，而國內車載以太網的研究和應用較少， 無法在車載以太網標準發布后快速進入應用階段。

g. 冗余技術方面， 冗余技術在保證未來智能汽車安全性和可靠性方面具有十分重要的作用， 國際上領先的電子電氣架構研發團隊提出多種冗余方式， 將冗余技術應用在整個電子電氣架構的開發過程中。國內目前更多將冗余技術應用于高級別自動駕駛系統的開發中。

二、產業技術發展趨勢

2.1 電子電氣架構演進

傳統汽車采用的分布式 EEA 因計算能力不足、 通訊帶寬不足、 不便于軟件升級等瓶頸，無法滿足現階段汽車發展的需求， EEA 升級將助力智能汽車實現跨越式革新。博世提出了眾所周知的電子電氣架構技術路線圖， 并描繪了未來電子架構的主要特征及可能的實現時間點。其中的兩個重要標志性節點依然值得強調， 即 DCU（域控制器） 或 HPC（高性能計算機）平臺的出現， 以及統一的基礎軟件平臺的出現， 標志著 EEA 的本質進化。

a.在基于域控的集中式架構之下， 各個功能部件均成為獨立的域， 在每個域之下有相應的控制功能集合。域與域之間可以做到安全隔離， 也可以根據需求進行通信和互操作， 形成類似以太網總線上的計算機局域網， 變成了松散耦合的架構。各域控制器完成各自的的數據處理， 并在域本地完成決策， 只通過中央網關與其它域控制器交換所需數據。其中， 與自動駕駛相關的傳感數據由自動駕駛域控制器處理后進行決策。

b.跨域融合架構：為進一步提升性能， 滿足協同執行又減少成本， 跨域融合集中化方案應運而生， 即將兩個或者多個集成型域控制器合并為一個域控制器。比如動力域和底盤域的合并、 車身域與智能座艙域的合并， 座艙域和自動駕駛域再集成至同一控制器硬件， 達到部分程度的中央域控。該架構示意圖如下圖所示：

c.在未來， 隨著高級別自動駕駛的規?；瘧?， 汽車電子及軟件功能大幅增長， 架構形式將向基于中央計算平臺的整車集中式電子電氣架構演進：各采集、 執行節點將原始數據通過網關傳輸到中央控制器處理， 所有數據的處理與決策制定都在這里完成。其中， 與自動駕駛相關的傳感數據也將由中央控制器處理后進行決策。

d.最終電子電氣架構將向車路云協同架構發展。車路云協同架構是利用新一代信息與通信技術， 將車、 路、 云的物理層、 信息層、 應用層連為一體， 進行融合感知、 決策與控制，可實現車輛行駛和交通運行安全、 效率等性能綜合提升的一種信息物理系統。

而整車中央集中化階段和跨域融合階段的本質不同是：一， 軟硬件完全分離， 且所有的ECU/DCU 共享同一套基礎軟件平臺。二， 相互獨立的功能應用搭載在一套高算力的車載計算機（HPC） 上， 且它的算力遠超階段二的 DCU。三， 基礎軟件平臺+功能獨立+HPC 將帶來規?；?， 即一套架構可以承載任何形式、 數量的功能及服務。

2.2 整車計算平臺形態演進

整車計算平臺主要分為三個部分， 自動駕駛集成平臺（ADIP， Automated Driving Integration Platform） 、 車控集成平臺（VIP， Vehicle Integration Platform） 以及座艙集成平臺（CIP， Cockpit Integration Platform）。VIP 的主要功能范圍是集成動力控制、 車身控制、 網關功能以及區域控制器控制和管理；

ADIP 的主要功能范圍是高階自動駕駛、 駕駛輔助以及車輛運動控制；

CIP 的主要功能范圍是娛樂以及網聯的功能集。同時它們之間都有功能交集，正是因為這些功能交集的存在， 整車計算平臺的形態也會存在多種， 如下圖

整車計算平臺功能交集（博世）

• 針對 ≤ SAE Level 2+ 應用場景， 如下圖所示有三種模式：

整車計算平臺三種模式（≤ SAE Level 2+）

Pattern A: 三個集成平臺之間相對獨立， 適合于 L2+應用；

Pattern B1: CIP 集成了 L2+的駕駛輔助功能；

Pattern B2: VIP 集成了 L2+的駕駛輔助功能；

Pattern C: xIP（Cross-domain Integration Platform， 跨域集成平臺） 集成了所有， 通常 ADIP 和 CIP 整合在一起也屬于這個范疇；

Pattern B2 方案， 目前的解決方案主要還是外擴一個單獨的算力芯片進行駕駛輔助的感知等處理。

Pattern B1 方案， 目前以及下一代的座艙芯片已有足夠的算力去直接集成駕駛輔助的功能， 無需單獨的硬件芯片， 一些整車企業已經把集成泊車功能作為第一步， 進一步集成 L2+的行車功能。

VIP 功能主要用來實現動力控制、 網關以及車身等基礎功能， 對于實時性有很高的要求。駕駛輔助功能是以數據驅動的開發方式， 持續頻繁地進行軟件迭代。把 VIP 和輔助駕駛功能糅合在一起， 復雜程度會很大， 并且在成本效率上也沒有明顯優勢。因此 Pattern B1 方案會優于 Pattern B2 方案。

總體而言， Pattern A 目前仍然會是實現 L2+的主要架構形式， 單獨的 ADIP 允許接入更多的傳感器， 可以實現更多的功能場景；針對 L2+的應用， Pattern B1 會優于 Pattern B2；長期發展方向會向著 Pattern C 去演變。

• 針對 ≥ SAE Level 3 應用場景， 如下圖所示有三種模式：

整車計算平臺三種模式（≥ SAE Level 3）

針對≥L3 應用， 自動駕駛的冗余是必要的：

Pattern A：ADIP 內部或外部冗余

Pattern B1: ADIP 和 CIP 組成冗余

Pattern B2: ADIP 和 VIP 組成冗余

Pattern C: xIP 內部實現冗余

總體而言， 針對 L3 或以上的應用， Pattern A 優于 Pattern B1， Pattern B1 優于 Pattern B2；長期發展方向會向著 Pattern C 去演變。

2.3 構建 SOA（面向服務架構）

2.3.1 SOA

面向服務的架構 SOA（Service-Oriented Architecture） 是一種軟件架構設計的理念和方法論， 也是 IT 行業企業軟件的一種主流架構風格， 是一個架構組件模型， 將軟件組件（稱為服務） 通過定義良好的標準接口和服務契約聯系起來。SOA 架構需從傳統電子電氣架構的“面向信號”轉變為“面向服務”， 將功能獨立出來。

其核心內涵即從本質上通過復用、 松耦合、 互操作等機制來提高軟件質量、 加快軟件研發效率、 使研發出來的產品能夠交互并靈活適應業務變化。

目標是如何最大限度地減少應用（或業務） 變化對已部署或正在運行的軟件系統帶來最小的沖擊， 以滿足長期治理的需求， 實現服務架構隨應用變化可持續性演化。

2.3.2 軟件的工業化生產

面對車載軟件龐大且仍在增加的軟件代碼量， 汽車行業開始借鑒 ICT（信息通信技術）行業的“軟件工廠”理念。比如戴姆勒旗下的全資軟件開發公司 MBition 正在打造軟件工廠，根據開發項目需求， 通過對軟件組件的標準化、 結構化運用， 實現快速開發。正如傳統制造業在上世紀初引入福特式流水線生產那樣， 軟件開發也正在從“定制化手工制作”向“自動化產線制造”轉變。

軟件工廠需為開發者提供可行的軟件框架、 配套的開發指令、 預設的程序模板、 可復用的代碼以及伴隨開發進程可以連續測試的環境。在此基礎上， 當軟件工廠收到一項開發需求時， 開發者能夠根據工廠現有能力拆解需求模塊， 并將其分配至各個“產品線”， 每個產品線再根據新需求識別可以復用和需要新開發的部分， 判斷開發工作所需資源， 最后部署開發、測試工具并完成任務。相比于傳統的“手工”開發模式， 軟件工廠可以提升軟件產品的一致性、品質和開發效率， 提前識別開發工作量， 前置風險， 使整個開發和部署流程更可預測，大大提升了車企對軟件工作的資源配置和進程管控能力。

2.3.3 軟件與服務成為差異化的關鍵

汽車電子電氣架構的變革使得汽車硬件體系趨于集中化， 軟件體系的差異化成為汽車價值差異化的關鍵?？萍脊具M入汽車行業推動了供應鏈生態體系的變化， 汽車產業鏈逐漸從整車企業、 一級、 二級供應商的線性關系演變為更加復雜的整車企業、 供應商和科技公司均參與的汽車新生態體系， 以及整個產業覆蓋汽車全生命周期的網狀關系。商業模式上也從出售汽車硬件發展為出售硬件與后續服務的轉變。研發流程也從軟硬件集成開發轉變為軟硬件解耦的獨立開發。新的整車電子電氣架構構成了未來智能網聯汽車的核心， 軟件和服務能力將成為未來汽車產業里最為重要的競爭力。

2.3.4 標準化的軟件架構將逐步建立

汽車軟件架構走向分層化、 模塊化， 使得應用層功能夠在不同車型、 硬件平臺、 操作系統上復用， 并且可以通過標準化接口對應用功能進行快速迭代升級。未來隨著智能網聯汽車的應用場景越來越豐富和逐漸固化， 在面向服務設計思想下， 在容器化和虛擬化技術的支持下， 汽車硬件設備趨向于具備通用性、 算例化和標準化特性。系統軟件和功能軟件將是汽車行業技術研發和應用的重點。整車企業將更多聚焦在產品定義、 應用算法開發及系統集成匹配等方面， 而底層共性的基礎軟件架構等可由專業的供應商提供。

2.3.5 汽車產業格局將被重塑

在軟件定義汽車時代， 整車企業為了掌握主導權并降低高昂的研發成本， 往往會選擇直接與具備較強的獨立算法研發能力的軟件供應商合作， 因此這些軟件供應商一躍成為了 Tier1廠商。未來， 軟件供應商的盈利模式有望發生轉變， 基礎平臺開發以許可費的形式收費， 功能模塊以版權費的形式收費及定制化的二次開發費用等?！坝布A埋， 軟件升級”成為當下車企的主流策略， 至 2025 年將成為 L3 及更高級別自動駕駛發展的關鍵節點， 具有領先軟件和算法能力的車企、 軟件供應商有望獲得重要發展機遇。

從長期來看， SOA 將重構汽車生態， 汽車行業或將復制 PC 和智能手機的軟件分工模式。車企可通過自建或與供應商合作搭建操作系統和 SOA 平臺， 引入大量算法供應商和合作伙伴等形成開發者生態圈， 汽車行業上下游參與者各自的角色與定位將發生根本

2.4 通信架構升級

隨著新一代架構的發展和自動駕駛的應用， 車載網絡技術的發展趨勢為高帶寬、 低延時、高可靠、 車云協同。汽車網絡通信系統朝向多網絡、 高帶寬、 低延時、 多冗余、 高可靠等方向發展， 同時打破核心技術壟斷， 提升自主化率， 逐步實現引領超越。

車載網絡技術趨勢

預計至 2025 年， CANFD-XL、 10Base-T1S、 2.5G+Base-T1 等車載總線技術將趨于成熟，逐漸量產應用。

預計至 2025 年， 隨著中央計算+區域控制器的架構逐漸實施， 將逐漸發展為以 1G+車載以太網為骨干網的網絡架構， 結合 AVB/TSN、 SOME/IP、 DDS 等傳輸協議， 解決低時延、 高帶寬、 高同步、 高冗余應用場景傳輸需求。

通信技術正在快速演進中， 從 CAN 到 CANFD 到 CAN XL, 從 100M 以太網到 1G 以太網到 2.5G 以太網， 甚至 10G 以太網的技術。

自動駕駛需要以更快速度采集并處理更多數據， 傳統汽車總線無法滿足低延時、 高吞吐量要求。因此， 集帶寬更寬、 低延時等諸多優點的以太網有望成為未來車載網絡骨干。2015 年首個車載以太網規范 100Base-T1 發布，僅需要一對雙絞線進行傳輸， 可以減少 70-80%的連接器成本， 減少 30%以上的重量， 并且能夠有效的滿足車內 EMC（電磁兼容性） 電磁干擾的要求。隨著 1000BASE-T1 以及更高帶寬 NGBase-T1 以太網標準的不斷推出， 以太網有望成為未來智能汽車時代的車載主干網絡。不過為了不使零部件成本和線纜重量急劇增加， 并且盡可能降低技術升級帶來的安全風險， 各域內依然保持 CAN/CAN FD 的連接架構。

2.5 功能安全、 網絡安全升級

隨著汽車智能化程度的不斷提高， 面對車內外通信的復雜環境和未知情況， 必須提高安全策略級別以應對復雜多變的外部環境。汽車架構的初期設計中需充分考慮安全保障， 并在在整個產品使用生命周期內確保安全性。根據新一代電子電氣架構的正向開發方式， 利用用戶思維、 軟件思維和硬件思維從整車、 系統和部件的角度開展從上到下的架構設計， 將安全體系融入其中， 并在汽車的整個生命周期內對安全保障進行維護。汽車的智能化使得監管和法規將《機器人安全總則》 三法則延伸到汽車產業上。所以最近這十年來， 汽車安全的監管和法規呈現三個趨勢：

• 從結果安全逐步向架構、 設計、 開發、 構建、 集成與測試、 生產制造等全過程安全 可控擴展；

• 從功能安全向網絡、 數據、 隱私等安全與合規擴展；汽車數字體驗需要不斷地獲取數據和服務， 而且功能要始終保持更新， 因此必須從一開始就在系統開發中考慮數據安全；

• 從整車安全向每個部件安全擴展。

2.6 計算芯片短期分化與長期融合

2.6.1 自動駕駛高性能芯片的定制化

由于自動駕駛算法仍具有高度不確定性， 芯片方案需兼顧目前 AI 算法的算力要求和靈活性， GPU（圖形處理器） +FPGA（現場可編程邏輯門陣列） 的組合受到大多數玩家的青睞。當自動駕駛技術路線相對成熟且進入大規模商用的階段后， GPU 也難以勝任對更多空間信息的整合處理， 需要定制的專用集成電路 ASIC（特定用途集成電路） 。ASIC 芯片可在相對低水平的能耗下， 提升車載信息的數據處理速度， 雖然研發和首次“開?！背杀靖?， 但量產成本低， 是算法成熟后理想的規?；鉀Q方案。然而， 魚和熊掌不可兼得， 低功耗、 大算力、 可編程靈活性（以應對算法的快速升級） 在短期內是無法完美兼顧的。

多核 SoC 將成為未來智能座艙主控芯片的主流。豐富生態的中控大屏系統、 “一芯多屏”系統、 AR-HUD 等多屏場景需求需要多核 SoC 進行支持。多核 SoC 芯片技術解決方案發展呈現多樣化， 如車機主控芯片+MCU 兼顧安全的方案以及集成式的座艙域控制器方案。

2.6.2 芯片的長期兼容與融合

遠期來看， 負責不同域的芯片架構將呈現兼容與融合趨勢。如前文所述， 短期內自動駕駛高性能芯片和座艙主控芯片分別演進。究其原因， 座艙應用場景和芯片性能要求已相對明晰， 并且消費電子級芯片可滿足座艙現有場景需求， 消費電子芯片可以利用規模優勢實現低成本商業化開發；相反， 自動駕駛技術路線尚不成熟， 其人工智能算法所要求的芯片性能遠高于目前消費電子芯片的能力， 因而在自身技術路線選擇下進行高成本、 小規模開發應用。據羅蘭貝格預測， 2030 年以后， 隨著自動駕駛技術路線的逐漸成熟， 高性能芯片進入標準化、規?；a階段， 其與座艙主控芯片進一步向中央計算芯片融合， 從而通過集成進一步提升運算效率并降低成本， 但由于自動駕駛和座艙安全要求不同， 滿足安全要求將成為融合的前提。

三、問題和挑戰

3.1 基礎軟件平臺規范、 接口不統一， 服務化架構剛起步

3.1.1 平臺規范層面

對于車載基礎軟件來說， 如何滿足整車電子電氣架構變化的需求， 是值得深入探討的關鍵問題。一方面， 基礎軟件平臺需要統一標準并兼容不同整車企業的應用， 另一方面， 基礎軟件平臺安全性需要重點加以考慮， 并給出系統性解決方案。

無論是域集中式架構還是基于中央計算平臺的架構， 整車功能設計， 控制邏輯都離不開高性能計算單元。高性能計算單元的引入增加了基礎軟件平臺的復雜度， 整車功能設計如何把握和駕馭這種復雜度成為首要問題。同時， 基于 SOA 的整車設計和功能服務化理念也對基礎軟件平臺產生了重要影響， 如何滿足新的設計和功能， 實現未來需求也是亟待解決的問題。

電子電氣架構基礎軟件平臺技術和測試要求的標準化和規范參考有助于形成軟件定義汽車的行業共識， 降低整車企業、 零部件供應商等之間的溝通成本， 實現應用軟件復用， 提高開發效率。不過國內汽車基礎軟件平臺產業及標準化及產業發展剛起步， 各行業組織或企業切入方式和領域不同， 有待形成進一步的共識。于此同時， 基礎軟件平臺的安全性也應從整車電子電氣架構視角考慮信息安全、 功能安全、 通信安全等。

3.1.2 接口層面

接口標準化主要是為智能駕駛、 智能交互等應用提供標準化的運行環境和服務， 滿足不同硬件外設可擴展、 即插即用以及功能/應用軟件包可升級、 可復用， 高效實現和互操作， 實現軟硬件分層解耦， 滿足跨平臺、 跨車型、 可擴展等要求。

當前汽車傳感器、 執行器等設備的物理接口、 電氣接口和通信接口還未實現標準化。以執行器為例， 執行器的物理接口受限于供應商及整車企業的布置以及產品延續性等因素， 其標準化進程較為艱難， 目前只局限于單個供應商內部的標準化或是單個整車企業內部的標準化。執行器的電氣接口當前多數為硬線驅動， 由于執行器的驅動方式不同， 導致其硬線的電氣接口也不盡相同；但這些年已慢慢向 CAN 或 LIN 接口的智能執行器方向發展， 節省大量的硬線線束與 ECU 硬線接口， 省去了接口電路的匹配工作， 診斷與刷寫程序更加便捷， 狀態監測以及故障診斷信息更加豐富， 為 ECU 電氣接口的通用化、 標準化提供了保障；而執行器的通信接口標準化目前還局限于單個供應商內部或是單個整車企業內部， 待電氣接口標準化后逐步完備。

此外， 在遠程服務和車云通信方面， 除了 GB/T 32960《電動汽車遠程服務與管理系統技術規范》 規定了電動汽車遠程服務與管理系統中協議結構、 通信連接、 數據包結構與定義、數據單元格式與定義， 其他智能駕駛車輛功能的車云交互數據種類、 格式、 協議以及信號各類屬性的標準化工作暫未有統一性的成果發布。

智能網聯和智能駕駛技術正在日新月異的進化中， 各汽車企業開發和應用電子電氣架構的技術路線各異， 架構服務化程度各異， 設備抽象和原子服務數據結構標準化對實現軟件定義汽車有著顯著價值， 同時接口標準化工作剛剛起步也面臨著極大的挑戰。

3.2 自主開發操作系統內核和虛擬化軟件的挑戰。

隨著汽車電子電氣架構的發展， 分布式架構向集中式架構過渡， 這需要域控制器在軟件層面利用虛擬化技術在一個處理器上集成多個操作系統與應用系統。虛擬化軟件層作為支持多個操作系統內核和應用系統同時運行的基礎模塊， 其安全性、 隔離性和時延小成為系統的關鍵要素。操作系統內核和虛擬化軟件是底層操作系統最為核心的基礎模塊， 同時也是保護系統安全的核心組件。智能網聯汽車的特殊屬性， 要求操作系統內核和虛擬化軟件應該滿足高實時、 高安全、 高性能和高可靠性。在功能安全和信息安全方面面臨著極其嚴苛的考驗。

3.3 工具鏈層面缺乏從電子電氣架構概念設計到產品系列開發的全過程的協同開發平臺。

針對汽車電子電氣系統復雜的開發過程， 比如急劇增加的車型功能特性及復雜度、 不同技術職能部門相關人員參與與設計交互、 不同車型的特性配置管理與方案評估等， 電子電氣系統設計工具需提供給用戶一個完整的協同開發平臺， 支持從電子電氣架構概念設計到產品系列開發的全過程。

當前工具鏈多為國外企業提供， 車規級芯片工具鏈平臺， 包括操作系統、 集成開發環境（IDE） 、 編譯器、 調試與燒錄工具、 開發評估套件、 底層驅動庫、 USB 協議棧、 TK 產品應用開發包、 無線產品應用開發包， 以及和實時操作系統供應商合作開發的嵌入式操作系統板級支持包。

但在面向新一代 EEA 的服務化設計方面， 缺少成熟工具鏈支撐， 特別是需要支持團隊協作甚至是跨地域的協作模式的服務設計平臺， 目前國內外較為缺乏。

3.4 智能網聯化對汽車通信技術提出了大帶寬和高實時性的要求。

通信協議棧是汽車電子電氣架構的重要組成部分， 基于 CAN 總線的信號傳輸已經無法滿足全部需求， 而新型總線的各類傳輸協議標準（如：TSN） 還在不斷完善， 上層應用協議的應用生態還沒有構建完成， 各整車企業在 SOME/IP、 DDS、 PCIE 的協議應用仍處于論證階段。TSN 國際、 國內標準中與車載相關的技術標準尚不全面， 并且支持 TSN 技術的芯片沒有達到車規級應用。SOME/IP 通信設計開發需實現基于服務的信號設計開發， 即在功能信號中提取 “服務”， 然后進行打包傳輸， 開發難度高。

3.5 中央計算硬件平臺芯片和設計方案尚不成熟

中央集中式電子電氣架構下的中央計算硬件平臺目前尚無成熟的芯片和硬件設計方案，需要整車與芯片供應商和硬件平臺供應商進行同步驗證開發。同時， 中央計算平臺對軟件開發能力要求也很高， 需協同基礎軟件、 應用軟件、 軟件集成等資源共同實現軟件設計工作。