一、產業(yè)發(fā)展現(xiàn)狀

1.1 國外整體產業(yè)發(fā)展現(xiàn)狀

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

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

博世 EEA 發(fā)展六階段

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

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

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

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

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

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

沃爾沃 EEA 架構示意圖

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

奧迪 EEA 架構示意圖

1.2 國內整體產業(yè)發(fā)展現(xiàn)狀

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

極氪汽車 EEA 架構示意圖

1.2.3 華為CCA架構

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

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

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

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

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

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

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

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

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

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

二、產業(yè)技術發(fā)展趨勢

2.1 電子電氣架構演進

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

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

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

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

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

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

2.2 整車計算平臺形態(tài)演進

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

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

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

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

• 針對 ≤ 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 方案， 目前以及下一代的座艙芯片已有足夠的算力去直接集成駕駛輔助的功能， 無需單獨的硬件芯片， 一些整車企業(yè)已經把集成泊車功能作為第一步， 進一步集成 L2+的行車功能。

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

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

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

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

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

Pattern A：ADIP 內部或外部冗余

Pattern B1: ADIP 和 CIP 組成冗余

Pattern B2: ADIP 和 VIP 組成冗余

Pattern C: xIP 內部實現(xiàn)冗余

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

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

2.3.1 SOA

面向服務的架構 SOA（Service-Oriented Architecture） 是一種軟件架構設計的理念和方法論， 也是 IT 行業(yè)企業(yè)軟件的一種主流架構風格， 是一個架構組件模型， 將軟件組件（稱為服務） 通過定義良好的標準接口和服務契約聯(lián)系起來。SOA 架構需從傳統(tǒng)電子電氣架構的“面向信號”轉變?yōu)椤懊嫦蚍铡保?將功能獨立出來。

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

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

2.3.2 軟件的工業(yè)化生產

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

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

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

汽車電子電氣架構的變革使得汽車硬件體系趨于集中化， 軟件體系的差異化成為汽車價值差異化的關鍵?？萍脊具M入汽車行業(yè)推動了供應鏈生態(tài)體系的變化， 汽車產業(yè)鏈逐漸從整車企業(yè)、 一級、 二級供應商的線性關系演變?yōu)楦訌碗s的整車企業(yè)、 供應商和科技公司均參與的汽車新生態(tài)體系， 以及整個產業(yè)覆蓋汽車全生命周期的網狀關系。商業(yè)模式上也從出售汽車硬件發(fā)展為出售硬件與后續(xù)服務的轉變。研發(fā)流程也從軟硬件集成開發(fā)轉變?yōu)檐浻布怦畹莫毩㈤_發(fā)。新的整車電子電氣架構構成了未來智能網聯(lián)汽車的核心， 軟件和服務能力將成為未來汽車產業(yè)里最為重要的競爭力。

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

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

2.3.5 汽車產業(yè)格局將被重塑

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

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

2.4 通信架構升級

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

車載網絡技術趨勢

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2 芯片的長期兼容與融合

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

三、問題和挑戰(zhàn)

3.1 基礎軟件平臺規(guī)范、 接口不統(tǒng)一， 服務化架構剛起步

3.1.1 平臺規(guī)范層面

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

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

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

3.1.2 接口層面

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

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

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

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

3.2 自主開發(fā)操作系統(tǒng)內核和虛擬化軟件的挑戰(zhàn)。

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

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

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

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

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

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

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

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

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