|
作者 / 阿寶 編輯 / 阿寶 出品 / 阿寶1990
【摘要】從汽車電動化、智能化對于電子電氣架構都需要非常大的變化，本文從電子電氣架構的起源，從分布式邁向集中式的架構為什么是軟件定義汽車的前提，伴隨著硬件、軟件、通訊架構的升級，在超級計算機還沒有到來之前，第三代EE架構是最佳的選擇，介紹了主流的第三代EE區域控制器的方案，主流的OEM廠家的架構趨勢。
全文的內容框架如上圖所示，全文1.5W字，預計閱讀時間25分鐘。
什么是電子電氣架構 在2007年由德爾福(DELPHI)首先提出E/E架構的概念，具體就是在功能需求、法規和設計要求等特定約束下，把汽車里的傳感器、中央處理器、電子電氣分配系統、軟件硬件通過技術手段整合在一起；通過這種結構，將動力總成、傳動系統、信息娛樂系統等信息轉化為實際的電源分配的物理布局、信號網絡、數據網絡、診斷、電源管理等電子電氣解決方案。 汽車電子電氣架構(EEA，Electrical/Electronic Architecture )，指對汽車的傳感器、執行器、ECU、線束、操作系統等整車軟硬件進行設計，進而實現車內高效的信號傳輸、線束布臵等效果。EEA 設計需要綜合考慮客戶功能需求，安裝、配臵、維護等方面的易程度和成本，并且需要具備適度的超前性。 通俗來說，汽車是一個軟硬件結合的產物，如果把它比作是一個人，「四個輪子 一個沙發」是身體，電子電氣架構就相當于神經系統，負責完成各個部位的連接，統領整個身體的運作，實現特定功能。 功能車時代，汽車一旦出廠，用戶體驗就基本固化；智能車時代，汽車常用常新，千人千面， 電子電氣架構向集中化演進是這一轉變的前提。從分布式到域控制再到集中式，隨著芯片和通信技術的發展，電子電氣架構正在發生巨大的變化。
電子電氣架構從分布式邁向集中式，時代的召喚，也是軟件定義汽車的前提 2.1 分布式架構為什么注定會成為歷史？ 電動化智能化浪潮來襲，汽車分布式電子電氣架構不堪重負已不能適應汽車智能化的進一步進化。智能駕駛、智能座艙是消費者能感知到的體驗，背后需要強大的傳感器、芯片，更需要先進的電子電氣架構的支持，電子電氣架構決定了智能化功能發揮的上限。如果沒有先進的電子電氣架構做支撐，再多表面智能功能的搭載也無法支持車輛的持續更新和持續領先，更無法帶來車輛成本降低和生產研發的高效。 最初，燃油車電子元器件數量有限，電子電氣架構并不復雜， OEM 根據不同 Tier1 的技術和價格優勢分別采購 ECM，只需要進行集成、測試和驗證，并不需要掌握技術細節和代碼。很長一段時間內， OEM 的工作只是根據市場需求不斷增加 ECM 和調整線束布臵，整車 EEA都是由 Tier1 配合 OEM 進行開發，強勢的 OEM 可以向 Tier1 提出功能導向的要求,其他 OEM在 ECU 設計制造上不具備話語權。 雖然 ECU 的數量和汽車配件的復雜程度只增不減，電動化引入三電系統更是加劇了這種態勢，但整個行業的慣性始終在強化。一方面， Tier1 缺乏進行自我革命的動力，更高性能的總線技術和 ECU 是主要戰場， 另一方面， OEM 考慮到對整車電子電氣架構進行重塑式改造的龐大投入也會有所猶豫。 打破行業僵局，特斯拉提供“拉力”，智能化浪潮提供“推力”。2017 年特斯拉用 Model 3 吹響改革的號角，新一代集中式電子電氣架構被推上舞臺，智能化的浪潮來臨。在Model 3 席卷全球的倒逼下，OEM 和 Tier1 都是必須有所行動。 分布式架構的極限是 L2 級別的自動駕駛，L3 級別已經超出承受范圍。以大眾分布式 MQB平臺為例，CAN 總線上已經掛了很多 ECU，如果再掛雷達，通信協議總量將不支持，把全部的 CAN 換成 2M 相當于做了半個架構的改造。 智能座艙和自動駕駛需要更多的 ECU 和傳感器，但分布式 EEA 已經到達瓶頸，算力和總線信號傳輸速度還遠遠不能滿足，因此必須引入搭載更高性能車規級芯片的域控制器、車輛以太網和集中式 EEA。根據 NXP 官網預測，2015-2025 年汽車中代碼量有望呈指數級增長，其年均復合增速約為 21%。 實現 OTA 和“軟件定義汽車”，智能車必須解耦軟硬件。分布式架構的 ECU 來自不同供應商，有著不同的嵌入式軟件和底層代碼，軟件生態復雜，OEM 無法自主進行整車維護，更無法實現 OTA。而 Tier1 更新 ECM 的周期和新車型的研發周期相匹配，一般為 2-3 年，率先實現 OTA 的特斯拉更新頻率則為幾個月一次，用戶體驗差異明顯。在特斯拉已經掌握 OTA 技術的情況下，如果不盡早開始布局，傳統車企或將重蹈諾基亞和摩托羅拉的覆轍。 2.2 汽車電子電氣架構的演進趨勢由分布式 ECU 向域控制/中央集中架構方向發展。從博世對 E/E 架構定義來看， 汽車 E/E 架構的升級路徑表現為分布式（模塊化→集成化）、 域集中（域控制集中→跨域融合）、 中央集中式（車載電腦→車-云計算）。 即為分布式 ECU（每個功能對應一個 ECU）逐漸模塊化、集成向域控制器（一般按照動力域、底盤域、車身域、信息娛樂域和 ADAS 域等），然后部分域開始跨域融合發展（如底盤和動力域功能安全、信息安全相似），并發展整合為中央計算平臺（即一個電腦），最后向云計算和車端計算（中央計算平臺）發展。其中車端計算主要用于車內部的實時處理，而云計算作為車端計算的補充，為智能汽車提供非實時性（如座艙部分場景可允許微秒級別的延遲）的數據交互和運算處理。 目前我們正處于從過去的分布式EE架構邁向域集中式EE架構的轉變過程中，預計到2025年左右就會完成這一轉變。從2025年以后，將開啟跨域的融合時代，也就是轉變為“中央 區域”（Central & Zonal）計算的EE架構時代。
博世對未來汽車電子電氣架構發展趨勢的觀點 2.2.1 模塊化階段一個 ECU 負責特定的功能，比如車上的燈光對應有一個控制器，門對應有一個控制器，無鑰匙系統 對應有一個控制器。隨著汽車功能增多這種架構日益復雜無法持續。 2.2.2 集成化階段單個 ECU 負責多個功能，ECU 數量較上一階段減少。在這兩個階段，汽車電子電氣架構仍處于分布式階段，ECU 功能集成度較低。 2.2.3 功能域控階段功能域即根據功能劃分的域控制器，最常見的是如博世劃分的五個功能域（動力域、底盤域、車身域、座艙域、自動駕駛域）。域控制器間通過以太網和 CANFD（CAN with Flexible Data-Rate）相連，其中座艙域和自動駕 駛域由于要處理大量數據，算力需求逐步增長。動力總成域、底盤域、車身域主要涉及控制指令計算及通訊資源，算力要求較低。 2.2.4 跨域融合階段在功能域基礎上，為進一步降低成本和增強協同，出現了跨域融合，即將多個域融合到一起，由跨域控制單元進行控制。比如將動力域、底盤域、車身域合并為整車控制域，從而將五個功能域（自動駕駛域、動力域、底盤域、座艙域、車身域）過渡到三個功能域（自動駕駛域、智能座艙域、車控域）。
博世劃分的功能域
聯合電子開發的電子電氣架構 2.2.5 中央計算 位置域階段隨著功能域的深度融合，功能域逐步升級為更加通用的計算平臺，從功能域跨入位置域（如中域、左域、右域）。區域控制器平臺（Zonal Control Unit，ZCU）是整車計算系統中某個局部的感知、數據處理、控制與執行單元。它負責連接車上某一個區域內的傳感器、執行器以及 ECU等，并負責該位置域內的傳感器數據的初步計算和處理，還負責本區域內的網絡協議轉換。位置域實現就近布置線束，降低成本，減少通信接口，更易于實現線束 的自動化組裝從而提高效率。傳感器、執行器等就近接入到附近的區域控制器中，能更好實現硬件擴展，區域控制器的結構管理更容易。區域接入 中央計算保證了整車架構的穩定性和功能的擴展性，新增的外部部件可以基于區域網關接入，硬件的可插拔設計支持算力不斷提升，充足的算力支持應用軟件在中央計算平臺迭代升級。 在一項針對某家整車制造商的研究中，安波福發現，使用區域控制器可以整合 9個 ECU，并少用數百根單獨電線，從而使車輛的重量減少了 8.5千克。減重有助于節能，并延長電動汽車的續駛里程。此外，由于區域控制器將車輛的基本電氣結構劃分為更易于管理的組成部分，更容易實現自動化線束組裝。
中央計算 區域控制架構 2.2.6 汽車云計算階段將汽車部分功能轉移至云端，車內架構進一步簡化。車的各種傳感器和執行器可被軟件定義和控制，汽車的零部件逐步變成標準件，徹底實現軟件定義汽車功能。
整車電子電氣架構必須要走向中央 區域集成 隨著整車電子電氣產品應用的增加，單車ECU數量激增，分布式電子電氣架構由于算力分散、布線復雜、軟硬件耦合深、通信帶寬瓶頸等缺點而無法適應汽車智能化的進一步發展，正向中央計算邁進。
分布式的電子電氣架構難以適應智能化發展趨勢
分布式與域控制器集中式電子電氣架構的優劣對比 汽車電子電氣架構的升級主要體現在硬件架構、軟件架構、通信架構三方面：
3.1 硬件架構升級：分布式向域控制/中央集中式發展3.1.1 硬件架構升級有利于提升算力利用率，減少算力設計總需求一般芯片在參數設計時按照需求值設計并留有余量，以保證算力冗余，主要因為汽車在實際運行過程中，大部分時間僅部分芯片執行運算工作，而且并未滿負荷運算，導致對于整車大部分運算處理能力處于閑置中，算力有效利用率較低。例如泊車使用的倒車影像等僅泊車等部分時段才執行運算操作。采用域控制器方式，可以在綜合情況下，設計較低的總算力，仍能保證整車在工作時總算力滿足設計要求。
同等功能應用條件下域控制算力設計需求更少 硬件架構對算力的需求，可類比保險。 若個人想要抵御風險， 需要大量資金儲備，因此大家都購買保險， 將匯集在一起的保險資金資源池來抵御個人風險，總資金量需求大大降低。分布式架構的芯片即為個人抵御風險儲備，而域控制/中央計算平臺即為總資金量，域控制/中央集中式顯然算力設計需求會更少。另一方面現階段傳統車的智能功能并不豐富，智能車在未來功能擴展等方面預留較多升級空間，若實現同功能應用、駕駛安全條件下進行對比，域控制/中央集中顯然更經濟；若僅為傳統車和智能車對比，智能車單車價值短期內顯然為上升的。 3.1.2 硬件架構升級有利于數據統一交互，實現整車功能協同傳統主機廠方案采用一個功能對應一套感知-決策-執行硬件，感知數據難以交互，也無法協同執行。而實現真正意義上的高級自動駕駛，不僅需要多傳感器共同感知外部環境，還需要對車內部各運行數據進行實時監控，統一綜合判斷，并且執行機構協同操作。域控制器/中央計算平臺可對采集的數據信息統一處理，綜合決策， 協同執行 分布式架構的感知數據無法統一決策處理，無異于盲人摸象。 例如，因單一傳感器 僅可識別到局部環境， 前方車上有一只寵物狗，各局部識別能力的傳感器可獲取到狗、 前車、路肩等，但因為無法實時交互，從而反饋到決策-執行層后易產生誤操作。而采用域控制/中央計算平臺方案可實現多種信息的融合處理，綜合判斷結果為一輛行駛在路上的車內有一只狗，從而執行合理的操作，提高行車安全性。 3.1.3 硬件架構升級有利于縮短線束，降低故障率，減輕質量。采用分布式架構， ECU增多后線束會更長，錯綜復雜的線束布置會導致互相電磁干擾，故障率提升，此外也意味著更重。集中式的控制器/中央計算平臺的方式可減少線束長度，減輕整車質量。 3.2 軟件架構升級：軟硬件由高度耦合向分層解耦發展3.2.1 軟件架構逐漸由 Classic AutoSAR 向 Classic AutoSAR Adaptive AutoSAR 混合式方向發展。AutoSAR 軟件架構主要分為 Classic AutoSAR 和 Adaptive AutoSAR 兩類，Classic AutoSAR 較為成熟，廣泛應用于傳統汽車嵌入式軟件中， Adaptive AutoSAR 尚處于發展初期，主要面向更復雜的域控制器/中央計算平臺等。 Classic AutoSAR 基礎軟件分為四層，分別為服務層、 ECU 抽象層、微控制器抽象層和運行時環境，運行時環境使應用軟件從底層軟件和硬件平臺相互獨立。除此之外還包括復雜驅動程序，由于對復雜傳感器和執行器進行操作的模塊涉及嚴格的時序問題，這部分暫時未被標準化。
Classic AutoSAR 體系架構
Classic AutoSAR 架構框圖 Adaptive AutoSAR 相較于 Classic AutoSAR 具有軟實時、可在線升級、操作系統可移植等優勢。Classic AutoSAR 是基于強實時性（微秒級） 的嵌入式操作系統上開發出來的軟件架構， 可滿足傳統汽車定制化的功能需求，但受網絡的延遲、干擾影響較大，無法滿足強實時性。隨著自動駕駛、車聯網等應用的復雜化， 軟實時性的軟件架構系統 Adaptive AutoSAR 誕生，其主要用于域控制器/中央計算平臺，相對于 Classic AutoSAR的優點：
Adaptive AutoSAR 較 Classic AutoSAR 優勢明顯 3.2.2 軟件架構升級有利于軟硬件解耦分層， 利于實現軟件/固件在線升級、軟件架構的軟實時、操作系統可移植。傳統汽車嵌入式軟件與硬件高度耦合，為應對越來越復雜的自動駕駛應用和功能安全需要，以AutoSAR 為代表的軟件架構提供接口標準化定義，模塊化設計，促使軟件通用性， 實現軟件架構的軟實時、在線升級、操作系統可移植等。 3.2.3 軟件架構升級有利于采集數據信息多功能應用，有效減少硬件需求量，真正實現軟件定義汽車。若未實現軟硬件解耦，一般情況下增加一個應用功能則需要單獨增加一套硬件裝置，采集的數據信息僅一個應用功能可以利用?，F階段，自動泊車雷達和自適應巡航的攝像頭、雷達采集數據不可交互，若打通整個汽車軟件架構，各數據特征有效利用，實現多個應用共用一套采集信息，有效減少硬件需求數量。 3.3 通信架構升級：LIN/CAN 向以太網發展大帶寬通信架構以適應車輛日益激增的數據量和低時延要求。自動駕駛需要以更快速度采集并處理更多數據，傳統汽車總線無法滿足低延時、高吞吐量要求。隨著汽車電子電氣架構日益復雜化， 其中傳感器、控制器和接口越來越多，自動駕駛也需要海量的數據用于實時分析決策，因此要求車內外通信具有高吞吐速率、低延時和多通信鏈路。在高吞吐速率方面， LIDAR 模塊產生約 70 Mbps 的數據流量，一個攝像頭產生約 40 Mbps 的數據流量， RADAR 模塊產生約 0.1Mbps 的數據流量。若L2 級自動駕駛需要使用 8 個 RADAR 和 3 個攝像頭，需要最大吞吐速率超過 120Mbps，而全自動駕駛對吞吐速率要求更高，傳統汽車總線不能滿足高速傳輸需求。
傳統汽車總線 3.3.1 LIN/CAN 總線向以太網方向發展， 滿足高速傳輸、低延遲等性能需求。由于智能網聯汽車應用越來越復雜，大量的非結構化數據（如圖片、視頻等）雖然攜帶的信息非常豐富，但其對數據傳輸要求極高，傳統汽車電子電氣架構的 LIN/CAN 總線不能滿足高速傳輸的需求。以太網因具備大帶寬、高通量、低延遲等優勢，將成為應用于汽車主干網絡的主要方案。
各域之間通過網關完成數據交換 3.3.2 采用以太網方案線束更短，同時也可減少安裝、測試成本線束在重量和成本方面都位列汽車零部件第三， 其中在成本方面，線束安裝占人工成本的 50%。根據 Broadcom和博世調查數據顯示， 達到同等性能條件下， 通過使用非屏蔽雙絞線（UTP） 的以太網電纜和更小的緊湊型連接器，連接成本最多可降低 80％，線纜重量最多可減輕 30％。
車載以太網的發展過程
未來車載以太網應用滲透率持續增加
域/中央集中式EEA對區控制器（ZCU）要求 4.1 一步到位的超級計算機不適合現在的車企在2022年9月20日晚，英偉達發布了全新的智能汽車芯片Thor。相比于公司去年發布的芯片Altan，Thor的AI算力提升了一倍，達到了2000TFLOPS，可同時滿足自動泊車、自動駕駛、車機、儀表盤以及駕駛員監測等六重汽車算力需求。Thor芯片是為汽車中央計算架構而生的產品。英偉達對Thor芯片的愿景是用它取代目前汽車內的單獨芯片，幫助車企降低生產的成本。但這種超級計算機真的適合現在的車企么？ 由于過去汽車上控制器相互獨立，軟件為嵌入式，整車做最終硬件集成即可。未來隨著 ECU 的減負，原先高度分散的功能集成至域控制器，主機廠必須自己掌握中央控制系統，否則就會失去對汽車產品的控制權。而把原本高度分散的控制功能逐步整合統一起來是傳統車企的全新必修課，因此車企對電子電氣架構的掌握是分步的、漸進式的。 特斯拉 Model3 開啟了電子電氣架構大變革，出現中央計算雛形 位置域，縮短 50%整車線束，未來目標是將整車線束降至100 米，在電子架構方面，特斯拉領先傳統車企 6年以上。除特斯拉以外，目前大部分的車企的電子電氣架構仍處于早期的功能域控制器階段，即部分功能集中到了功能域控制器，但還有保留較多分布式模塊，即“分布式 ECU 域控制器”的過渡方案，避免因為變革程度太大導致額外的風險及成本。 大部分企業規劃的下一代跨域融合電子電氣架構將于 2022年量產，以實現軟件高度集中于域控制器，逐步減少分布式 ECU。到 2025 年部分車企落地中央計算 區域控制器的電子電氣架構，從而實現軟硬件的進一步集成，軟件所有權逐步收歸主機廠。朝著“中央計算 區域控制”的架構演進的過程可能長達 5-10 年。
主流車企電子電氣架構進化節奏不一 4.2 區控制器在架構中的定位不管是域集中式還是中央EEA架構，區控制器（ZCU,Zonal ECU）都是重要的一部分，在電子電氣架構中ZCU主要充當部分功能Soc、網關、交換機和智能接線盒的角色；提供并分配數據和電力，并實現車輛特定區域的功能。
區控制器的一種設計方案 具體來講： 4.2.1 關于數據分發
4.2.2 關于分級配電（供電）
4.2.3 關于車輛特定區域的feature實現
4.2.4 接口支持
ZCU除了以上基本特性外，可能也會涉及到一些變遷，比如逐步“吸收”區內其他ECU的功能。第一階段，可能是相對通用化的ZCU，采用標準化軟件模塊，兼容現有ECU網絡（CAN/LIN/FlaxRay）；作為數據轉發設備，將區內的功能在服務層面就行抽象；第二個階段，會以降低區內ECU數量為目的，整合其他ECU功能，并將控制I/O虛擬化。可能帶來的影響：ZCU的對于計算需求增大，MCU難以滿足算力需求，可能還需要增加MPU（增加純DMIPS算力的SOC，比如Denverton甚至Xeon）來滿足算力需求。
ZCU與區內其他傳感器與執行器之間的配合關系（區內架構圖）
區控制器的“擴張”和功能的集中化趨勢 4.3 區域控制解決方案介紹4.3.1 英飛凌TC3xx/TC4xx在區域控制器的解決方案區域控制器是汽車中的節點，在汽車的一個物理區域內，為各傳感器、執行器等設備提供電源分配，數據連接和I/O采集與驅動需求。MCU是區域控制器的大腦，區域控制器中的MCU一般需要具備強大的處理能力，有很豐富的通訊接口，同時具備一定功能安全和信息安全等級。下面介紹區域控制器的一些關鍵技術和MCU解決方案。 TC3xx微控制器是第2代AURIX?產品，搭載了多達六個TriCore? 1.62嵌入式內核，每個內核的時鐘頻率最高可達300MHz。下圖是TC3xx家族中的TC39x系列MCU模塊圖，TC39x的算力達到了4000 DMIPS。
TC39x Block Diagram TC4xx微控制器是第3代AURIX?產品，搭載了多達六個TriCore? 1.8嵌入式內核，每個內核的時鐘頻率最高可達500MHz，并且集成一個PPU協處理器，可實現快速向量運算，基礎神經網絡算法以及其它一些復雜數學算法。PPU在未來的區域控制器中可以被應用于建模，模型預測控制以及防入侵檢測等一些信息安全算法中。下圖是TC4xx家族中的TC4Dx MCU的模塊圖，TC4Dx的算力達到了8000DMIPS 72GFlops*1。72GFlops是由PPU貢獻的。
TC4Dx Block Diagram 在區域控制器體系中，每個傳感器和執行器都根據其位置連接到本地區域控制器，然后區域控制器執行一些數據幀格式轉換，匯總數據并通過高速以太網將數據傳送至中央處理單元。區域控制器一般通過控制器CAN或LIN總線和掛載在它上面的傳感器和執行器通信，或者通過低速以太網或LVDS與攝像頭或其他ADAS傳感器進行通信。這就要求區域控制器的主控MCU有豐富的CAN和LIN的通訊接口以及高速以太網接口。在區域控制器進行數據轉發的過程中，還需要考慮通信延遲的問題，在中央集中式架構中，大部分的控制和執行命令是由中央處理單元發出，有些命令（例如底盤和動力）對于延時有嚴格的要求，因此對于區域控制器中從高速以太網轉發到CAN/LIN/低速以太網接口的延時時間也有了要求。TC3xx/TC4xx家族產品都有豐富的CAN/LIN/Ethernet通訊接口。
TC4xx產品中更是集成專用的硬件通訊路由模塊CRE (CAN Routine Engine)/DRE (Data Routine Engine)。TC4xx中的一個CAN模塊中集成了4個CAN 節點，當相同模塊中的CAN節點進行數據通信時，可以通過CRE直接實現CAN數據轉發，無需CPU和軟件介入。當不同模塊中CAN節點進行數據轉發或者CAN節點和以太網之間進行數據轉發，則可以通過CRE DRE的方式直接實現數據轉發，也無需CPU和軟件介入。
TC4xx CRE & DRE 這種硬件路由引擎直接實現數據轉發的方式大大減少了數據延遲，CAN到Ethernet的轉發延時最少可以到15us，CAN到CAN的轉發延時最少可以到5us。 在未來的中央集成EE架構中，通訊數據量不斷增加，高速以太網逐漸成為EE架構中的主干網。而為了考慮數據通信安全和冗余，以太網環網架構逐漸成為主流，區域控制器和中央控制單元則都是以太網環網架中的節點。TC4Dx中有2路5Gbps的高速以太網接口和4路10/100Mbps接口，2路高速以太網接入以太網環網（1進1出），4路低速以太網則可以接雷達或者攝像頭傳感器。2路高速以太網可以通過內部集成的高速以太網橋（G-Ethernet Bridge）直接進行以太網幀轉發。4路低速以太網接口之間也可以通過低速以太網橋（L-Ethernet Bridge）直接進行以太網幀轉發。低速以太網接口和高速以太網接口之間也可以通過低速以太網橋 DRE 高速以太網橋直接進行以太網幀轉發。這種方式大大減少以太網接口之間數據轉發的延時時間。
TC4xx Ethernet Bridge TC3xx/TC4xx以太網控制器支持的AVB/TSN協議如下：
4.3.2 瑞薩RH850 U2A/U2B區域架構解決方案瑞薩RH850/U2x高性能微控制器產品線用于下一代區域/內建ECU，支持豐富的嵌入式HW關鍵功能，這些功能是區域應用所特有的，如Hypervisor HW支持、QoS（僅U2B支持）、功能安全和信息安全，以實現無干擾。最重要的是，高性能的NoC（片上網絡）結構可以確保每個單獨內建的應用程序在外設和內存連接方面的實時行為。
瑞薩的RH850/U2A微控制器（MCU）被設計為高端車身和底盤應用的跨域平臺，以滿足日益增長的將多種應用內建到單個芯片的需求。基于28奈米制程技術，32位RH850/U2A MCU建立在瑞薩用于底盤控制的RH850/Px系列和用于車身控制的RH850/Fx系列的關鍵功能之上，以提供更好的性能。
RH850/U2A架構圖 瑞薩RH850/U2B系列以RH850/U2A的優勢為基礎，為解決未來幾代汽車的創新E/E架構的挑戰而定制。憑借其新的性能水平和高達32MB的內存整合度，RH850/U2B的定位高于RH850/U2A系列，以滿足未來汽車整合平臺概念的更多要求，同時與系統單芯片（SoC）相比，仍然提供具有成本優勢的MCU解決方案。
RH850/U2B架構圖 主要特性:
先進的接口
支持功能安全與網絡安全
廣泛的生態系統支持有關工具，硬件和軟件領域的最新標準 虛擬機監控程序支持 4.3.3 歐治半導體龍泉565 龍泉560 區域處理器芯片解決方案歐冶主要聚焦汽車第三代E/E架構（中央 Zonal區域架構）的核心訴求，為重新定義汽車提供完備、完善的基礎能力，做汽車智能化的使能者。
針對智能汽車需求，歐冶半導體可以提供完整領先的第三代E/E架構芯片解決方案，為電動汽車和燃油汽車的智能車燈及基本型端側智能部件、CMS電子后視鏡及增強型端側智能部件，以及L2/L2 行泊一體ADAS和ZCU區域處理器應用提供高性能、低成本車規級SOC芯片解決方案。 其中，歐冶通過龍泉560 龍泉565芯片組合完整覆蓋了ZCU的全場景業務需求，可以為智能汽車提供高性能、低成本的智能ZCU區域處理器解決方案，滿足智能化區域所需的高性能邊緣計算、實時通信、智能供電需求。 歐冶ZCU芯片方案集成高性能R核和M核處理器，集成低延遲CAN/LIN通信處理器和高性能車載以太網交換處理器，內置大容量的片內SRAM和NVM，內置豐富的外圍接口，可以滿足智能汽車ZCU區域控制器對實時性處理、車載以太網處理、功能安全和網絡安全的需求。同時，歐冶ZCU芯片方案支持多路視頻AI處理能力，為智能汽車ZCU區域應用預留了充足的能力。另外歐冶芯片配套提供成熟、穩定、易用的SDK和平臺化解決方案，可以滿足客戶產品快速量產需求。 5、整車 EEA，行業發展階段與展望5.1 特斯拉 Model3 開啟電子電氣架構的全面變革特斯拉是汽車電子電氣架構的全面變革者， 2012年 Model S 有較為明顯的功能域劃分，包括動力域、底盤域、車身域， ADAS模塊橫跨了動力和底盤域，由于傳統域架構無法滿足自動駕駛技術的發展和軟件定義汽車的需求，為解耦軟硬件，搭載算力更強大的主控芯片，必須先進行電子電氣架構的變革，因此 2017 年特斯拉推出的 Model3 突破了功能域的框架，實現了中央計算 區域控制器框架， 通過搭建異域融合架構 自主軟件平臺，不僅實現軟件定義汽車，還有效降低整車成本，提高效率：
特斯拉 Model3基本實現了中央集中式架構的雛形，不過 Model3距離真正的中央集中式架構還有相當距離：通訊架構以 CAN總線為主，中央計算模塊只是形式上將影音娛樂 MCU、自動駕駛 FSD以及車內外聯網模塊集成在一塊板子上，且各模塊獨立運行各自的操作系統。但無論如何， Model3 已經踐行了中央計算 區域控制的電子電氣架構理念框架，領先傳統車企 6 年左右。 通過三款車型的演進，特斯拉的新型電子電氣架構不僅實現了 ECU數量的大幅減少、線束大幅縮短（ MODEL S 線束 3000米， Model 3 減少一半以上），更打破了汽車產業舊有的零部件供應體系（即軟硬件深度耦合打包出售給主機廠，主機廠議價能力差，后續功能調整困難），真正實現了軟件定義汽車， 特斯拉的 OTA 可以改變制動距離、開通座椅加熱，提供個性化的用戶體驗， 由于突破了功能域，特斯拉的域控制器橫跨車身、 座艙、底盤及動力域，這使得車輛的功能迭代更為靈活， 用戶可以體驗到車是常用常新的，與之形成鮮明對比的是，大部分傳統車廠的 OTA 僅限于車載信息娛樂等功能。 特斯拉為了更好地發揮軟件的作用，實現了自動駕駛主控芯片這一最為核心的智能硬件的自研自制（特斯拉認為芯片的專用設計使得其上的軟件運行更高效）， 這意味著后續特斯拉車輛的升級速度、 功能的部署都不再依賴外部 SOC芯片供應商，真正將車輛的靈魂掌握在自己手中。
特斯拉電子電氣架構演進歷史 Model 3整車四個控制器包括中央計算模塊（ CCM）、左車身控制模塊(BCM LH)、右車身控制模塊(BCM RH)和前車身控制模塊（ BCM FH）四大域控制器。 左車身控制模塊負責左車身便利性控制以及轉向、制動、助力等。右車身控制模塊負責右車身便利性控制、 底盤安全系統、動力系統、熱管理等。中央計算模塊包括自動駕駛模塊、信息娛樂模塊、車內外通信連接，共用一套液冷系統。自動駕駛及娛樂控制模塊接管與輔助駕駛有關的傳感器——攝像頭、毫米波雷達， 將對算力需求較高的智能駕駛、信息娛樂放在一起，便于智能硬件持續升級， 2019年特斯拉推出自研 FSD芯片替換了基于英偉達 Drive PX2 芯片組， AI計算性能提升達 21倍，隨著特斯拉將自動駕駛最核心的計算硬件實現自研，特斯拉大幅提升了相對于競爭對手的領先優勢。操作系統基于開源 Linux進行定制化裁剪，并自研中間件，軟硬件均實現了自主可控，車型功能迭代更新速度加快，整車開發成本降低。
特斯拉Model3電子電氣架構
特斯拉自動駕駛主控芯片發展歷程 5.2 小鵬汽車G9電子電氣架構具領先性新勢力三強中小鵬汽車在電子電氣架構方面走得比較領先，隨著車型從 G3、P7和P5，迭代到 G9 的這套X-EEA3.0電子電氣架構，已經進入到中央集中式電子電氣架構。憑借領先一代的架構，搭載更高算力SOC芯片及更高算力利用率，小鵬G9或成首款支持 XPILOT 4.0 智能輔助駕駛系統的量產車。 小鵬P7搭載小鵬第二代電子電氣架構，具備混合式的特點：
因此 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 電力架構方面， 可實現場景式精準配電，可根據駕駛、第三空間等不同用車場景按需配電，比如在路邊等人時，可以只對空調、座椅調節、音樂等功能供電，其他部分斷電，這樣就能實現節能耗節省，提高續航里程。車輛定期自診斷，主動發現問題，引導維修，以科技手段賦能售后。
小鵬汽車第三代電子電氣架構實現千兆以太網 中央計算 區域控制 5.3 寶馬新一代電子電氣架構2018年寶馬量產了其新一代電子電氣架構，如圖1所示，其大量使用了以太網通信，并且域控制器也得到了使用，跟當年量產的Model 3的電子電氣架構有的一比了。
寶馬2018年電子電氣網絡架構 上圖各控制節點的含義如下圖所示，例如ACSM表示高級碰撞安全模塊，AHM表示拖車模塊，DSC為動態穩定控制模塊，BDC表示車身控制模塊，EGS表示電子變速箱控制模塊，HU-H表示娛樂控制模塊，PCU表示動力控制模塊，RAM表示音頻接收模塊，KAFAS表示基于攝像頭的駕駛員輔助系統，IHKA為集成集成自動暖氣/空調模塊，SAS表示選裝模塊，即為ADAS模塊，SMBF表示駕駛員座椅控制模塊。
各節點的具體含義 各節點之間的通信方式包括以太網、FlexRay、CAN總線，其中圖1所示中灰色表示以太網總線，包括兩線的OABR以太網和五線以太網，無線以太網主要用于BDC與OBD2之間的交互，單獨的以太網通信節點如下圖所示，深紅色表示FlexRay總線，黃色表示CAN總線。CAN總線中又分K-CAN、PT-CAN、Local CAN，K-CAN表示通信CAN，K-CAN1用于BDC與音頻接收模塊RAM、FZD通信，K-CAN5用于BDC與NFC、遠程接收器FBD，K-CAN6用于BDC與右燈光控制模塊FLER、左燈光控制模塊FLEL通信；PT-CAN為BDC與動力相關模塊，包括DME、DHC等模塊，Local-CAN為SAS，即ADAS控制器與傳感器單元通信。 其中最值得一提的是SAS、BDC、HU-H分別為ADAS、車身、座艙域控制器，三者之中都集成了以太網交換機和網關。
以太網通信節點 5.3.1 寶馬未來電子電氣架構發展以上是寶馬現在正在使用的電子電氣架構，那其在未來的如何呢？ 在ADAS方面，BMW的自動駕駛硬件架構采用的是增量式發展，比如L2的硬件架構可以作為L3/4/5級的備份，如下圖所示。分別包含mPAD，hPAD，uPAD。
寶馬未來的ADAS硬件系統 而在電子電器架構方面，寶馬也在探討在中央計算平臺架構下的動態可配置系統(Dynamic Reconfigurable System,簡稱DRS)，在滿足功能安全的前提下，在Zonal控制器層面進行動態配置，使得其可以快速和之前的設計的ECU進行兼容。 寶馬的動態可配置系統如圖14所示，其中分為三層，最底層為依賴硬件的電子電氣架構，主要是執行器和傳統的ECU，中間層為面向服務的系統，主要是是區域控制器ZCU組成，最上層為中央計算平臺。其中最底層與中間層通過CAN總線進行通信，ZCU之間或者是ZCU與上層計算平臺之間通過以太網進行通信。DRS的目的是實現基于處理器的Fail-Operational，目標是檢測HDS和和ZCU本身的故障，然后采取相應的措施，保證功能正常運行。 |
|
|
