作者 / 阿寶

編輯 / 阿寶

出品/阿寶1990

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

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

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

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

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

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

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

特斯拉 Model 3 ECU 圖示

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

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

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

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

沃爾沃 EEA 架構(gòu)示意圖

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

奧迪 EEA 架構(gòu)示意圖

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

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

1.2.1 小鵬汽車G9電子電氣架構(gòu)具領(lǐng)先性

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

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

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

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

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

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

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

小鵬汽車電子電氣架構(gòu)演進歷史

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

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

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

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

基礎(chǔ)軟件平臺：多個整車基礎(chǔ)功能軟件均形成標準服務(wù)接口且在車輛量產(chǎn)前凍結(jié)， 可復(fù)用于不同車型；

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

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

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

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

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

1.2.2 極氪001汽車電子電氣架構(gòu)

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

極氪汽車 EEA 架構(gòu)示意圖

1.2.3 華為CCA架構(gòu)

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

1.3 國內(nèi)外架構(gòu)整體方案對比

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

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

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

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

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

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

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

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

二、產(chǎn)業(yè)技術(shù)發(fā)展趨勢

2.1 電子電氣架構(gòu)演進

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

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

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

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

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

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

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

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

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

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

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

針對 ≤ SAE Level 2+ 應(yīng)用場景， 如下圖所示有三種模式：

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

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

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

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

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

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

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

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

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

針對 ≥ SAE Level 3 應(yīng)用場景， 如下圖所示有三種模式：

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

針對≥L3 應(yīng)用， 自動駕駛的冗余是必要的：

Pattern A：ADIP 內(nèi)部或外部冗余

Pattern B1: ADIP 和 CIP 組成冗余

Pattern B2: ADIP 和 VIP 組成冗余

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

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

2.3 構(gòu)建 SOA（面向服務(wù)架構(gòu)）

2.3.1 SOA

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

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

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

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

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

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

2.3.3 軟件與服務(wù)成為差異化的關(guān)鍵

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

2.3.4 標準化的軟件架構(gòu)將逐步建立

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

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

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

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

2.4 通信架構(gòu)升級

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

車載網(wǎng)絡(luò)技術(shù)趨勢

預(yù)計至 2025 年， CANFD-XL、 10Base-T1S、 2.5G+Base-T1 等車載總線技術(shù)將趨于成熟，逐漸量產(chǎn)應(yīng)用。

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

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

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

2.5 功能安全、 網(wǎng)絡(luò)安全升級

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

從結(jié)果安全逐步向架構(gòu)、 設(shè)計、 開發(fā)、 構(gòu)建、 集成與測試、 生產(chǎn)制造等全過程安全可控擴展；

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

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

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

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

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

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

2.6.2 芯片的長期兼容與融合

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

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

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

3.1.1 平臺規(guī)范層面

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

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

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

3.1.2 接口層面

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：湯梓紅