今天小編分享的科技經驗：智能網聯汽車電子電氣架構（上），歡迎閱讀。
新能源汽車是最近幾年非常火爆的領網域，在這個領網域中，電氣架構又是非常重要的一環。之前網絡上相關的内容非常少，作者的這篇文章，完整而系統地梳理了整個行業的發展現狀和趨勢，非常值得行業内的同學和想要入行的同學學習。
一、產業發展現狀
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 ECU 圖示
目前最有名的是特斯拉 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 國内整體產業發展現狀
目前，國内主流汽車企業三化融合車型的電子電氣架構方案已從完全分布式控制，進入網域集中式控制。 國内造車新勢力普遍直接采用功能網域控到網域融合的過渡方案，網域融合方案普遍集中在智能駕駛和智能座艙。
歡迎關注我的微信公眾号：阿寶1990，每天給你汽車幹貨，我們始于車，但不止于車。
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 軟體與服務成為差異化的關鍵
汽車電子電氣架構的變革使得汽車硬體體系趨于集中化，軟體體系的差異化成為汽車價值差異化的關鍵。科技公司進入汽車行業推動了供應鏈生态體系的變化，汽車產業鏈逐漸從整車企業、一級、二級供應商的線性關系演變為更加復雜的整車企業、供應商和科技公司均參與的汽車新生态體系，以及整個產業覆蓋汽車全生命周期的網狀關系。商業模式上也從出售汽車硬體發展為出售硬體與後續服務的轉變。研發流程也從軟硬體集成開發轉變為軟硬體解耦的獨立開發。新的整車電子電氣架構構成了未來智能網聯汽車的核心，軟體和服務能力将成為未來汽車產業裡最為重要的競争力。
2.3.4 标準化的軟體架構将逐步建立
汽車軟體架構走向分層化、模塊化，使得應用層功能夠在不同車型、硬體平台、作業系統上復用，并且可以通過标準化接口對應用功能進行快速迭代更新。
未來随着智能網聯汽車的應用場景越來越豐富和逐漸固化，在面向服務設計思想下，在容器化和虛拟化技術的支持下，汽車硬體設備趨向于具備通用性、算例化和标準化特性。系統軟體和功能軟體将是汽車行業技術研發和應用的重點。整車企業将更多聚焦在產品定義、應用算法開發及系統集成匹配等方面，而底層共性的基礎軟體架構等可由專業的供應商提供。
2.3.5 汽車產業格局将被重塑
在軟體定義汽車時代，整車企業為了掌握主導權并降低高昂的研發成本，往往會選擇直接與具備較強的獨立算法研發能力的軟體供應商合作，因此這些軟體供應商一躍成為了 Tier1廠商。未來，軟體供應商的盈利模式有望發生轉變，基礎平台開發以許可費的形式收費，功能模塊以版權費的形式收費及定制化的二次開發費用等。"硬體預埋，軟體更新"成為當下車企的主流策略，至 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 芯片可在相對低水平的能耗下，提升車載信息的數據處理速度，雖然研發和首次"開模"成本高，但量產成本低，是算法成熟後理想的規模化解決方案。
然而，魚和熊掌不可兼得，低功耗、大算力、可編程靈活性（以應對算法的快速更新） 在短期内是無法完美兼顧的。
多核 SoC 将成為未來智能座艙主控芯片的主流。豐富生态的中控大屏系統、"一芯多屏"系統、AR-HUD 等多屏場景需求需要多核 SoC 進行支持。多核 SoC 芯片技術解決方案發展呈現多樣化，如車機主控芯片+MCU 兼顧安全的方案以及集成式的座艙網域控制器方案。
2.6.2 芯片的長期兼容與融合
遠期來看，負責不同網域的芯片架構将呈現兼容與融合趨勢。
如前文所述，短期内自動駕駛高性能芯片和座艙主控芯片分别演進。究其原因，座艙應用場景和芯片性能要求已相對明晰，并且消費電子級芯片可滿足座艙現有場景需求，消費電子芯片可以利用規模優勢實現低成本商業化開發；相反，自動駕駛技術路線尚不成熟，其人工智能算法所要求的芯片性能遠高于目前消費電子芯片的能力，因而在自身技術路線選擇下進行高成本、小規模開發應用。
據羅蘭貝格預測，2030 年以後，随着自動駕駛技術路線的逐漸成熟，高性能芯片進入标準化、規模化生產階段，其與座艙主控芯片進一步向中央計算芯片融合，從而通過集成進一步提升運算效率并降低成本，但由于自動駕駛和座艙安全要求不同，滿足安全要求将成為融合的前提。
三、問題和挑戰
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 中央計算硬體平台芯片和設計方案尚不成熟
中央集中式電子電氣架構下的中央計算硬體平台目前尚無成熟的芯片和硬體設計方案，需要整車與芯片供應商和硬體平台供應商進行同步驗證開發。同時，中央計算平台對軟體開發能力要求也很高，需協同基礎軟體、應用軟體、軟體集成等資源共同實現軟體設計工作。
作者：阿寶說車，微信公眾号：阿寶1990
本文由 @阿寶說車 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 unsplash，基于 CC0 協定
