智能座艙、智能駕駛和智能網聯的發展將會促使新功能的不斷增加。同時，對高算力和大帶寬數據傳輸的需求也會越來越迫切，再加上“軟件定義汽車”的理念驅動，共同推動著整車EE架構的升級和變革；目前各車企已經逐步開始從獨立功能的分布式架構，走向功能集成的域控制架構，并將最終走向中央計算+區域控制的中央集中式架構。

一、特斯拉的“準中央集中式架構”引領了潮流

1. 分布式架構VS中央集中式架構

1）在分布式架構下，軟硬件緊密耦合，OEM對于供應商比較依賴，在合作的過程中，主要只是提供一個技術標準(比如通訊信息-XX信號，通訊形式-CAN/LIN等)給到Tier1，并且每個系統由不同的供應商提供，導致OEM的整車軟件成為由很多獨立的、不兼容的軟件系統組成的混合體。如果主機廠想進行功能變更或者增加新的功能，需要和不同供應商去談，因此受供應商掣肘十分明顯。

其次，隨著ECU越來越多，車內的線束也會越來越長，不僅增加了車重和整車成本，同時也給整車布置及裝配帶來了很大的困擾。并且，各個ECU之間的計算能力無法協同，產生較大的算力浪費。

2）在中央計算+區域架構下，算力逐漸向中央集中，先是由多個ECU合并成一個域控制器，慢慢的多個域控制器會繼續融合，最終會形成1個中央計算平臺+N個區域控制器的終極布局。此時，ECU數量會大大縮減，不僅降低了整車ECU的應用成本和控制器之間的布線成本,也有利于整車的輕量化設計。 

其次，傳感器、執行器就近接入到附近的區域控制器中，能夠更好的實現硬件的擴展。同時，區域控制器的結構形式也更易于管理，容易實現線束的自動化組裝。

2. 特斯拉的“準中央集中式架構”到底是怎樣的？

2019年，特斯拉已經在Model3上實現了中央計算+區域控制器的EE架構方案，引領了潮流，那么特斯拉的這種架構究竟有哪些優勢呢？

特斯拉Model3的車電子電氣架構分為四大部分：CCM(中央計算模塊)、BCM FH（前車身控制模塊）、BCM LH(左車身控制模塊)、BCM RH(右車身控制模塊)。其中CCM(中央計算模塊)由三個模塊組合而成：信息娛樂系統(IVI)，駕駛輔助系統(ADAS)和車內外通信系統。

1）前車身控制模塊：負責整車電源分配，車輛前艙用電器的邏輯控制和驅動；

2）左車身控制模塊：負責左側用電器的配電，左側用電器的邏輯控制和驅動，包括左車身便利性控制以及轉向、制動等底盤控制等；

3）右車身控制模塊：負責右側用電器的配電，右側和背部用電器的邏輯控制和驅動，包括右車身便利性控制、動力系統、空調等。

特斯拉EE架構的優勢：

1）智能駕駛模塊的硬件部分采用了自研的FSD芯片；對于軟件部分，操作系統基于開源Linux進行定制化裁剪，同時自研中間件。實現了軟硬件自主可控，這樣既有利于加快車型功能的的迭代更新速度，又大大降低了整車開發成本。

2）軟件架構層面，采用了SOA架構思想，便于SOTA的部署以及云端數據的收集和分析。

特斯拉電子電氣架構的先進性是毋庸置疑的，它的中央計算模塊-CCM將智能駕駛模塊、影音娛樂模塊以及車內外網聯模塊集成在一起，并共用一套液冷系統。基本上實現了中央集中式架構的雛形，但并不是嚴格意義上的中央集中式架構，業內把這種類型稱之為“準中央集中式架構”。

因此，即便是特斯拉，它距離真正的中央集中式架構也是還有一段路要走。基于當時技術成熟度和成本考慮：1）通訊架構依然較為傳統，以CAN總線為主，控制仍分布在MCU上，且MCU基礎軟件統一采用FREE RTOS；

2）中央計算模塊CCM屬于分離式：只是形式上將影音娛樂的MCU、智能駕駛的FSD以及車內外外網聯模塊集成在了一個板子上，但是每個模塊依然是獨立運行各自的操作系統，并獨立完成各自的任務。

即使如此，特斯拉依然是中央計算+區域控制架構最先進理念的踐行者，引發了業界其他同行的學習和追趕。

二、國內特斯拉EE架構的“追趕者”

在智能化和軟件定義汽車時代，誰能掌握EE架構和軟件的主導權，誰就能占據智能汽車市場的制高點。因此，國內主流整車企業也都在積極進行相關布局，“準中央集中式”架構方案的量產車型集中在2022-2023年左右推出。

但是，各家OEM規劃的中央集中式架構形式上并不是太統一。比如，上汽零束的整車計算平臺采用兩個HPC高性能計算單元；廣汽或者長城的方案采用中央計算平臺、智能駕駛域和智能座艙域三大計算平臺。但總體上來講，研發設計理念大同小異：硬件上采用中央計算+區域控制的架構方案，軟件上采用SOA軟件架構的設計理念。

1.  上汽零束 - 銀河全棧3.0方案

硬件平臺方面：由兩個HPC高性能計算單元HPC1和HPC2以及四個區域控制器（ZONE）構成。兩個高性能計算單元作為整車的計算中心，用于實現智能座艙、智能駕駛以及智能駕駛冗余備份等功能；4個區域控制器用于實現各自不同區域的相關功能。

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

備注：

1）2021年8月，上汽零束與芯馳科技達成戰略合作，將基于零束銀河全棧3.0架構，共同制定芯片及整車電子電氣架構的發展路線圖；同時，雙方將圍繞芯片級底層軟件操作系統、虛擬化平臺技術，共同探討、聯合開發適用全棧3.0的狹義操作系統；2）2021年9月，上汽零束宣布與創時科技聯合設計開發基于“零束銀河全棧3.0”的云管端一體化艙駕融合HPC。

軟件平臺方面：采用云管端SOA一體化軟件平臺

1）軟件平臺與硬件芯片以及操作系統解耦，即使不同EE架構平臺的芯片類型和操作系統不一樣，軟件平臺依然可以平移過來復用。比如零束的1.0架構平臺和3.0架構平臺，雖然底層硬件和操作系統不一樣，但依然采用的是同一個軟件平臺。

2）在應用層，通過中間件和SOA原子服務層，使得向上能夠提供統一、標準的API接口，能夠讓應用層開發更輕松，復用性更高。同時，再加上軟件平臺SDK，可以讓OEM、供應商、第三方開發者和用戶都可以加入到應用開發中來，實現應用生態共創。

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

2.  廣汽埃安 - 星靈架構

1）硬件平臺方面：星靈架構由數字鏡像云 、3個核心單元模塊和4個區域控制器（左/右/前/后）構成。其中，3個核心計算機模塊包括中央運算單元、智駕域控制模塊和座艙域控制模塊；中央運算單元涵蓋了新能源控制模塊和車身控制模塊，負責控制車輛行駛、制動和車輛設備等功能。

• 中央運算單元搭載NXP S32G399網關計算芯片，由8個A核+4個M核構成，并且內置LLCE+PFE加速引擎，通信延遲≤20μs；
• 座艙域控制模塊搭載高通8155/8295芯片，7nm制程，具備105K DMIPS算力，支持3D人物形象渲染、人臉識別、AR-HUD等功能；
• 智駕域控制模塊搭載華為昇騰610高性能芯片，7nm制程，支持200~400TOPS的算力拓展，ISP的圖像處理能力可達2.4GPix/s，能夠應對高速、城市等復雜道路情況。

星靈架構硬件平臺（圖片來源:廣汽埃安宣講資料）

2）軟件平臺方面：采用了分層設計的SOA軟件架構

• 基礎中間層采用原子服務封裝和標準化接口；
• 專用中間層采用增強型組合服務，可獨立執行；
• APP軟件層是與底層解耦的獨立組件，可直接調用服務。

該軟件架構實現了組件服務化、原子化和標準化，軟硬件解耦，提升OTA能力和速度，同時實現硬件的即插即用——增加新的應用模塊即可實現新的場景。

星靈架構軟件平臺（圖片來源:廣汽埃安宣講資料）

3. 長城汽車- GEEP4.0架構

1）硬件平臺方面：GEEP4.0架構由中央計算平臺（CCU）、智能座艙模塊（HUT）、智能駕駛模塊（ICU），以及3個區域控制器（VIU_L 、VIU_R以及VIU_F）組成。

中央計算單元CCU的主要職責是把輔助自動駕駛、動力、底盤、車身、空調、車身狀態以及模式管理等各個域的功能做集中的處理，在高階自動駕駛配置下，CCU可以作為L3域控制器的備份，實現最低風險條件。

3個區域控制器：是一個標準化的控制單元，按照車身域進行劃分、部署和開發，分別布置在左邊、右邊和前邊，負責將周邊的一些MCU就行整合，也就是將ECU、電源、控制器、輸入/輸出做一個整合。目前三個VIU的大部分軟件算法已經上移到CCU中，由長城軟件團隊開發，VIU僅僅保留了很少一部分邏輯，更多是承擔驅動I/O的作用。

 GEEP4.0硬件平臺（圖片來源:長城汽車技術分享沙龍宣講資料）

2）軟件平臺方面

• 應用軟件層面，將大數據、云診斷、信息安全等軟件系統融合，實現功能集成；
• 在不同核部署不同域的軟件 - MCU核采用CP Autosar，在多個MCU核分別部署不同域電控軟件；HPC核采用Linux OS和AP Autosar中間件；
• 通過在不同的核部署不同域的軟件，在橫向打通了多域之間的融合，在縱向打通了底層硬件、操作系統(CP autosar、Linux OS)、中間件（AP autosar）、協議棧以及應用軟件之間的通訊；
• 支持FOTA，規劃部分舒適性功能將支持SOA。

GEEP4.0軟件平臺（圖片來源:長城汽車技術分享沙龍宣講資料）

4. 小鵬X-EEA3.0

2021年11月，小鵬汽車在廣州車展上發布了小鵬G9，計劃于2022年上市；該車采用小鵬全新的X-EEA 3.0架構。目前小鵬官方關尚未透露過多具體的技術細節，筆者整理了以下幾點信息供大家參考：

• 硬件架構：中央超算 + 區域控制；
• 軟件平臺架構分為三層：系統軟件平臺、基礎軟件平臺和智能應用平臺；
• 通信架構：采用千兆以太網通信；
• 數據架構：實現無感OTA - 域控制器均將內存進行分區隔離控制，一個區用于升級，一個區用于車輛正常運行；因此即使當車輛正常行駛的時候，依然可以同時進行新功能的OTA升級；
• 電力架構：用電設備供電可控，根據用戶場景進行智能化精準配電，減少不必要的電力浪費，讓電力得到最優化的利用。

三、EE架構升級變革帶來的影響

1. 供應鏈體系的重塑

在傳統分布式架構下，軟件與ECU高度耦合。OEM對Tier1有較強的依賴關系，Tier1占據主導地位，軟硬件以打包的方式直接供給OEM。產業鏈相對比較簡單，上游是軟件產品供應商/芯片供應商（Tier2），中游是零部件集成商（Tier1），下游便是整車集成廠（OEM）。 隨著電子電氣架構的升級變革，硬件逐漸的標準化，軟件從硬件中剝離出來，軟件和硬件實現解耦，使得由軟件來定義汽車成為了現實。因此，OEM對掌握軟件定義汽車的能力變得更加的強烈，他們希望能夠逐漸的從Tier1手中奪回期盼已久的“主導權”。 為此，有進取心的OEM開始組建軟件團隊提升自己的軟件研發能力，但畢竟還是有很長一段的路要走。在這樣的背景下，一些人看到了車企對“自研可控”合作模式的強烈需求，于是出現了新的物種 — Tier1.5，向上可以支持OEM產品的自定義，向下可集成和整合Tier2的資源，以期能夠在這場“主導權”爭奪戰中分一杯羹。與此同時，傳統Tier1為了維護自己的主導權地位，也紛紛開始進行垂直整合，打造軟硬件全棧的研發能力，由零部件供應商向系統方案解決商轉型，即由Tier1提升至Tier0.5 - 不僅可以為OEM提供軟硬一體化的產品，還可提供從前期技術研發到后期數據共享等環節的全流程服務，希望能夠繼續保持和OEM之間的“親密”關系。

2. 行業競爭格局的改變

當前進行先進EE架構研發的企業大致可以分為三類：整車企業、Tier1和科技公司。整車企業掌握中央集中式EE架構核心技術和部件主導權的動機比較強烈，因為他們已經看到了這種主導權給特斯拉帶來的好處。但短期內能夠實現這些技術和部件全部自研的整車企業仍是少數。大多數整車企業仍將依賴 Tier1 、科技公司以及其他供應商共同去完成。

整車電子電氣架構的開發工程復雜且技術鏈路長，只有產業鏈上的玩家在各個環節能夠相互協作，發揮各自的優勢，并能夠形成合力，起到1+1大于2的效果。這樣才能幫助整車企業更快地完成架構的升級換代。

對于OEM而言，會依據自身實際情況選擇適合自己的合作方式：

1）對于研發能力較強的頭部車企，比如特斯拉，在芯片、操作系統、中間件、域控制器系統集成等關鍵核心領域都會選擇自研，而對于一些硬件的生產會選擇外包。

其次，自動駕駛感知算法相對比較復雜，即使是一些頭部車企，在感知算法方面也會選擇與業內實力較強的軟件公司進行聯合開發。在這個過程中，他們多半也會偷師學藝，逐漸提升自己的感知算法能力，最終向全棧自研的目標靠攏。

2）對于軟件研發能力相對較弱的車企，則需要分清楚什么是共性的，什么是個性的。考慮到自身的研發實力及成本的壓力，共性部分只能選擇戰略性地放棄，交給合適的供應商來幫助其完成開發；對于個性的部分，則需要盡自己最大的努力去做好差異化，打造出自己的品牌力。例如域控制器或者中央計算平臺，就需要通過有全棧研發能力Tier1或者軟件公司來幫助其逐步分層打開，然后自己在應用層做個性化和差異化的開發。

目前，主機廠的需求是個性化和多元化的，大都傾向于根據自己的需求要求供應商進行定制化開發。同時，OEM也在竭力提升自身的軟件開發能力；從長期來看，對于Tier1和打算去做Tier1的科技公司而言，域控制器或中央計算平臺的部分軟件功能的開發權被主機廠“收回”已是大勢所趨。因此，Tier1和科技公司也在極力打造軟硬件的全棧技術研發能力，以避免淪為OEM的“硬件代工廠”。

3. EE架構的向上突破帶來的新機遇

在智能駕駛進入下半場競賽的關鍵時期，OEM開始升級自己的電子電氣架構，以應對汽車智能化和網聯化的發展。在這個關鍵的時間窗口，誰能夠幫助OEM率先實現硬件模塊化的快速替換和迭代升級，以及軟件模塊的可移植和最大化重用，誰便能獲得主機廠的青睞，便能率先在新的市場站穩腳跟。

所謂時勢造英雄，那么哪些類型比較容易出現“新風口”上的“英雄”呢？筆者判斷會有以下幾種類型：

1）大算力AI芯片公司 - 電子電氣架構向域集中和中央域控快速發展，對主機廠來說，對高性能大算力計算平臺的選擇是當務之急。因此大算力芯片的供應商將迎來不斷增長的市場空間。尤其是國內最近成長起來的一些芯片公司 —— 開放的系統方案，對本地化場景的理解能力，以及良好的工程配套服務能力是其當前的優勢所在。

2）域控制器集成商 - 隨著整車電子電氣架構的升級，推動了域控制器滲透率的提升，域控制器這一新興的市場未來會有很大的增長空間。具備可靠的產品質量，同時還能夠幫OEM大大節省成本和縮短開發周期的域控制器集成商，將會迎來發展的契機。

3）基礎軟件平臺供應商 - 對于軟件勢力稍弱的OEM，對于基礎的軟件平臺這種共性的部分，沒有必要進行重復開發，因為它是不會被消費者感知到的東西。因此可以選擇把這部分交給合適的基礎軟件平臺供應商去做，這樣既可以降低自己的開發難度和開發成本，同時還能夠把自身的人力和財力用于關鍵的個性化開發部分；有利于縮短產品開發周期，并盡快將其推向市場。

四、實現中央計算+區域控制架構的挑戰是什么？

1. 底層“芯片”基礎決定上層“架構”高度

高階自動駕駛對算力的需求越來越高，搭載制程更先進、性能更強悍的芯片已經成為架構設計時所要考慮的首要問題，因為所計劃采用芯片的量產時間會影響到架構方案的落地時間。

在設計中央計算+區域架構的時候，中央計算平臺需要同時滿足各域的需求和特性，為此需要算力更強的芯片以及各種操作系統的組合，最大的挑戰就是選取可用的芯片。但目前尚未有量產的芯片能夠同時滿足幾大功能域的要求，因此多數主機廠的還是采用多個芯片拼湊的方案：

1）車控系統：一般采用MCU，運行成熟的Classic AUTOSAR基礎軟件，實時性和安全等級要求高，但是算力和存儲有限。

2）智能座艙和智能駕駛域，需要高性能、大算力的SoC芯片，并且還需要運行復雜的操作系統，并輔以中間件。

其次，現在入局車載領域的大算力、高性能芯片的玩家越來越多，同時芯片的迭代速度也越來越快，如果每次更換芯片都需要對整個技術架構進行重構，將會嚴重影響新產品的開發速度。因此，中央計算平臺需要具有較好的拓展性，既需要擁有統一的傳感器及外設接口，還需要具備良好的芯片兼容性。

2. 軟件能力和軟件團隊建設

軟件能力 - 目前主流功能域架構可劃分為五個域：車身域、底盤域、動力域、智能座艙域、自動駕駛域。在向中央集中式架構發展的過程中，必然要做跨域融合，比如把車身域、底盤域以及動力域整合為一個整車控制域，以后的終極目標是所有功能域全部集成到一個中央大腦上來。在這樣的發展過程中，不僅需要自建大量的軟件功能服務能力；與此同時，更需要強大的軟件能力去應對底層的實時操作系統、AUTOSAR以及其他關鍵軟件模塊之間的系統協同。

軟件能力的另外一個體現，就是OTA，尤其是FOTA，需要OEM具備強大的軟件開發能力，能夠開發底層執行件的控制軟件，才能夠真正實現軟件定義汽車的功能或者性能。

2018年美國《消費者報告》雜志指出，Model3在高速行駛狀態下緊急剎車方面存在嚴重問題。當Model3以60英里/小時行駛時，其制動距離約為46.3米，高于同級別其它車型。為解決此問題，Model 3 通過遠程推送固件升級。最終的結果是通過OTA，Model3的緊急剎車距離縮短了大約6.1米。

Model 3 制動系統的硬件采用的是博世的iBooster，但底層的電控軟件是特斯拉自研的，因此才能通過OTA升級，實現了對剎車踏板特性的調節，即通過調整剎車響應曲線來實現整個剎車過程中的制動力最優化的分配，從而縮短了剎車距離。

軟件團隊建設 - OEM若要實現真正的軟件定義汽車，即車輛的絕大多數功能和性能都由自己來定義，那么對其自身的研發能力，特別是軟件的研發能力，都將是一個比較大的考驗。現在有實力的OEM都在大規模的組建軟件研發團隊，軟件開發人員在人才市場上已經明顯供不應求了。甚至出現了即使舍得用高薪和期權去“引誘”，也難以“套”到合適人才的尷尬局面。同時，軟件團隊的管理和協調也比較復雜，這也是傳統OEM需要重新進行強化學習的地方。

3. 組織體系的問題   

傳統OEM具備多年逐步搭建和完善起來的研發團隊、產品體系以及供應鏈體系。但是，在進行整車EE架構變革的時候需要考慮和顧忌的東西會更多，比如，原來生產線的可復用性問題，架構對龐大產品線的兼容性問題，以及全球各地的供應鏈問題等等。

中央集中式架構的一大特點是算力向中央集中，這樣的話，肯定會砍掉很多ECU。如果車上有大量ECU被砍掉，對于依賴這些部件的員工以及與之相關供應商來說，這是生死攸關的事情。如果他們無法在內部和外部做好調整，那么新的架構就很難快速地被推進和實施。

從某種程度上講，傳統OEM憑借多年積攢起來的供應鏈以及產品體系優勢等，現在卻成了一把“雙刃劍”，開始阻礙他們進行架構的創新。因此，他們在進行架構改革的時候根本不太可能“一刀切”，全盤推倒以前的方案，全部轉換到新的E/E架構上來，只能利用現有資源分階段地向前過渡和演進，并逐步提升自身的軟件研發能力和改變自身的研發組織架構去適應新的研發流程。

而造車新勢力則沒有這方面顧慮，完全可以從零開始。雖然沒有像傳統OEM積累那么多的過往資源，同時它也沒有之前的歷史包袱，完全可以毫無顧忌大膽地去做新的嘗試。

因此，從這一層面上講，傳統OEM龐大的組織體系的確拖了他們的后腿。