集中化已成為掌控現(xiàn)代汽車中計算密集型功能的核心驅(qū)動力。在下一代汽車的開發(fā)進程中，架構變革正受到高級駕駛輔助系統(tǒng)（ADAS）、車輛互聯(lián)性、信息娛樂系統(tǒng)以及由此引發(fā)的網(wǎng)絡安全需求的深刻影響。當前，已有眾多研究聚焦于未來集中式電氣/電子（E/E）架構的構建，以及實現(xiàn)集中化的各類技術途徑。然而，一個亟待解決的問題是，目前尚缺乏一套系統(tǒng)化的方法，用于深入剖析現(xiàn)有系統(tǒng)，并精準挖掘其在功能層面的集中化潛力。

鑒于此，本文提出了一種創(chuàng)新方法。該方法以常見的 E/E 架構設計理念以及當前研究領域所提及的相關工具為基礎，助力系統(tǒng)設計師或工程師對功能進行抽象化提煉。通過這種抽象化處理，設計師能夠設計出更為集中化的系統(tǒng)架構，以更好地適應現(xiàn)代汽車的發(fā)展需求。

基于該方法，設計師可以進一步提出全新的系統(tǒng)架構方案，并對這些方案展開全面討論與細致權衡，深入剖析其各自的優(yōu)缺點。為驗證該方法的有效性，本文通過逐步將其應用于現(xiàn)代電動汽車的進氣降額功能進行了實踐檢驗。

后續(xù)的討論表明，影響集中化潛力的因素紛繁復雜，多種多樣。并且從整體來看，集中化未必是所有功能和系統(tǒng)的未來演進方向，不同功能和系統(tǒng)應根據(jù)自身特性與需求，審慎選擇適合的發(fā)展路徑。

一、背景信息

在戴姆勒（Daimler）、福特（Ford）、雷諾（Renault）等資深汽車制造商中，面向領域的電氣/電子（E/E）架構已然成為行業(yè)實踐的標桿。這類垂直架構的顯著特征在于，每個領域大致劃分為五個區(qū)域，每個區(qū)域都集成了大量專用電子控制單元（ECU），使得功能高度分散于各個部件[1]。然而，這種垂直架構的弊端也日益凸顯，其缺乏必要的靈活性與可擴展性，難以契合汽車行業(yè)當下的發(fā)展趨勢。如今，新入局者正試圖從零起步，打破傳統(tǒng)束縛，在市場中謀求一席之地并獲取設計自由。

高級駕駛輔助系統(tǒng)（ADAS）對強大計算能力的迫切需求，促使傳統(tǒng)E/E架構面臨重新設計的挑戰(zhàn)。與此同時，現(xiàn)代汽車的互聯(lián)性變革，如與萬維網(wǎng)服務的深度融合、TCP/IP協(xié)議的廣泛應用，以及對高帶寬信息娛樂系統(tǒng)的追求，都在有力地推動著E/E架構向集中化方向發(fā)展。此外，車輛的互聯(lián)性還帶來了嚴峻的網(wǎng)絡安全挑戰(zhàn)，這對E/E架構的設計提出了更高要求。

在汽車行業(yè)成本壓力持續(xù)攀升的背景下，那些分散且已趨于成熟的傳統(tǒng)平臺，在可擴展性方面遭遇瓶頸，難以應對日益復雜的行業(yè)環(huán)境。通過對比特斯拉Model Y、大眾ID.4和福特Mach E的電子控制單元（ECU）數(shù)量及通信網(wǎng)絡情況，這一觀點得以進一步印證。其中，大眾和福特仍受傳統(tǒng)平臺的桎梏，發(fā)展步伐相對遲緩。實際上，成熟的汽車原始設備制造商（OEM）并未采取激進的變革策略，而是選擇穩(wěn)步推進、漸進演進。

眾多一級供應商敏銳捕捉到行業(yè)變革的契機，紛紛推出面向區(qū)域E/E架構的集中式高性能計算（HPC）ECU。這些ECU作為核心組件，周圍環(huán)繞著智能執(zhí)行器和傳感器，形成了一套高效協(xié)同的系統(tǒng)。這一設計理念將計算能力與輸入/輸出（I/O）功能有效分離，將復雜功能集中整合至單一ECU中，從而實現(xiàn)對系統(tǒng)復雜性的精準把控。此外，一級供應商在解決方案中普遍采用了面向服務的設計和通信方法，這一技術手段能夠高效處理未來將急劇增長的海量數(shù)據(jù)。

當前，公司內(nèi)部垂直整合的趨勢愈發(fā)明顯，這為E/E架構的集中化提供了有力支撐。隨著員工專業(yè)知識的不斷積累與深化，集中化架構的推廣與應用變得更加可行。在本研究中，我們基于前人的研究成果，深入剖析了集中化E/E架構的技術實現(xiàn)路徑與結構設計方法。隨后，我們將這些方法進行系統(tǒng)整合，形成了一套全面且具有可操作性的方法體系。同時，我們也對集中化的局限性進行了客觀、深入的批判性討論。在深入探討集中化方法之前，我們首先對面向領域和面向區(qū)域的E/E架構的特點進行了詳細闡述，以便為后續(xù)方法的分類與探討奠定堅實基礎。

二、 主導的E/E架構及趨勢

1、面向領域的E/E架構

在面向領域的電氣/電子（E/E）架構體系里，頂層核心組件為領域控制器，它猶如架構的“智慧大腦”，是一個性能強勁的主CPU，肩負著控制和監(jiān)測特定領域（如動力系統(tǒng)領域）的重任。領域控制器具備強大的功能整合能力，能夠巧妙地對各類功能進行捆綁與集成，以此從容應對日益攀升的復雜性和計算能力需求。

在領域控制器之下，分布著一系列計算能力相對較弱的專用電子控制單元（ECU）。這些專用ECU各司其職，專注于處理特定的功能任務。由于這些任務可能對硬件有特殊要求，或者需要部署在特定的位置，因此這些ECU的存在十分必要。它們通過典型的通信網(wǎng)絡與領域控制器緊密相連，形成了一個有機的整體。例如，對于簡單的輸入/輸出（I/O）執(zhí)行器控制和傳感器監(jiān)控任務，通常采用LIN網(wǎng)絡進行通信；而對于高度交互式的ECU之間的數(shù)據(jù)交互，則多選用CAN網(wǎng)絡。為進一步提升數(shù)據(jù)傳輸速率，速率高達5 Mbit/s的CAN-FD網(wǎng)絡被廣泛應用，在當前以集中化為主導的發(fā)展潮流下，它基本能夠滿足面向領域的E/E架構的數(shù)據(jù)傳輸需求。盡管汽車以太網(wǎng)能夠?qū)崿F(xiàn)更高的數(shù)據(jù)速率，但目前它更多地被用作兩個或多個領域之間的骨干通信路徑，承擔著數(shù)據(jù)傳輸?shù)摹案咚俟贰苯巧?。如圖清晰展示了這種面向領域的E/E架構的一個典型示例。

通常情況下，一輛車中會劃分出四到五個領域。以梅賽德斯 - 奔馳（Mercedes-Benz）為例，其劃分的領域涵蓋信息娛樂和遠程信息處理、車身與舒適性、高級駕駛輔助系統(tǒng)（ADAS）以及動力系統(tǒng)等。這些領域在相關文獻中也代表了汽車領域架構中的主要劃分方向。

2、局限性與挑戰(zhàn)

高級駕駛輔助系統(tǒng)（ADAS）與動力系統(tǒng)這兩個關鍵領域，充分暴露了面向領域的電氣/電子（E/E）架構可能存在的固有局限。在自動駕駛這一前沿目標的實現(xiàn)進程中，這兩個領域需要開展深度且緊密的協(xié)同合作。然而，現(xiàn)實情況是，大量信息需要在不同領域之間頻繁且高效地交換，這一過程不可避免地導致功能在一定程度上呈現(xiàn)出分散和去中心化的態(tài)勢。

隨著自動駕駛實現(xiàn)復雜性的不斷提升，以及所需接口數(shù)量的急劇增加，面向領域的E/E架構在可管理性和可擴展性方面逐漸力不從心，性能表現(xiàn)大打折扣。在此背景下，對現(xiàn)有的E/E架構進行全面評估與重新設計，推動其朝著跨領域或面向區(qū)域的E/E架構方向演進，已成為提升汽車系統(tǒng)整體性能與競爭力的必然選擇。接下來，我們將深入介紹這兩種新型架構及其獨特特點。

3、 跨領域和面向區(qū)域的E/E架構

跨領域E/E架構在架構演進歷程中，扮演著向面向區(qū)域的E/E架構過渡的關鍵中間角色。跨領域控制器通過巧妙整合不同領域的核心功能，實現(xiàn)了自身能力的質(zhì)的飛躍。這些被整合的功能往往具有許多共同接口，或者對專用軟件和硬件有著共同的要求。通過深度挖掘并充分利用這些協(xié)同效應，跨領域控制器顯著提高了系統(tǒng)實現(xiàn)效率、性能表現(xiàn)以及通信能力，進一步強化了車輛功能的可管理性和可擴展性，為汽車系統(tǒng)的智能化升級奠定了堅實基礎。

在跨領域E/E架構的基礎上進一步深化集中化，便迎來了面向區(qū)域的E/E架構。正如引言中所提及的，眾多一級供應商已敏銳捕捉到這一發(fā)展趨勢，并積極投身于面向區(qū)域的E/E架構的研發(fā)與推廣之中。面向區(qū)域的E/E架構的顯著特點在于，它擁有一個功能強大的中央主控單元，該單元猶如車輛的“智慧中樞”，承擔著車載計算機的核心角色。通過虛擬化、容器化等前沿技術解決方案，中央主控單元成功整合了以往分散在各個領域控制器的功能，實現(xiàn)了資源的高效利用與功能的深度融合。關于這些技術解決方案的詳細探討，將在后續(xù)內(nèi)容中展開。

在車輛的其他部分，物理上被合理劃分為多個區(qū)域，每個區(qū)域都配備了一個區(qū)域控制器，作為輸入/輸出（I/O）硬件（例如無法集中化的執(zhí)行器或傳感器）的網(wǎng)關。這些網(wǎng)關區(qū)域控制器承擔著信號轉(zhuǎn)換的重要任務，確保中央計算機與各個區(qū)域之間的信號能夠準確、高效地傳輸。在選擇直接信號線和通信通道類型時，必須充分考慮硬件特性以及所需的帶寬，以確保系統(tǒng)通信的穩(wěn)定性和可靠性。下圖直觀展示了一個典型的面向區(qū)域的E/E架構，為我們深入理解這一架構提供了清晰的參考。

4、局限性與挑戰(zhàn)

在相關文獻中探討集中化架構的利弊時，多數(shù)觀點傾向于肯定集中化的積極意義，尤其聚焦于車輛技術在當下與未來的發(fā)展需求。然而，集中化并非完美無缺，存在兩個亟待重視的缺點，需通過技術革新、方法論優(yōu)化以及設計針對性的解決方案來加以克服。

集中式電氣/電子（E/E）架構顯著特征之一是線纜長度和截斷導線數(shù)量大幅攀升。這不僅增加了布線的復雜度和成本，還可能對車輛的電磁兼容性和可靠性產(chǎn)生不利影響。不過，通過智能化的線纜設計以及合理的區(qū)域布局規(guī)劃，這一難題有望得到有效解決。

集中化系統(tǒng)面臨著一個更為關鍵且棘手的挑戰(zhàn)——單點故障問題。一旦中央計算機出現(xiàn)故障，整個車輛將陷入癱瘓，無法正常運行。在車輛的設計與開發(fā)階段，無論是軟件層面還是硬件層面，都必須將這一風險因素納入考量，嚴格遵循汽車行業(yè)的汽車安全完整性等級（ASIL）要求，確保車輛在各種工況下都能安全可靠地運行。

實現(xiàn)向面向區(qū)域的E/E架構轉(zhuǎn)型的技術路徑豐富多樣，但每一種路徑都伴隨著相應的挑戰(zhàn)。這些技術方法將在后續(xù)章節(jié)中詳細介紹，并作為設計功能抽象和功能集中化系統(tǒng)化方法的重要依據(jù)。

5、集中化的技術方法

在本章中，我們將依據(jù)AUTOSAR這一開放且標準化的軟件架構，從電子控制單元（ECU）的底層硬件到頂層軟件，對實現(xiàn)集中化的技術方法進行全面分類。通過這種方式，我們能夠確保與當前車輛架構保持緊密聯(lián)系，避免技術轉(zhuǎn)型過程中的脫節(jié)現(xiàn)象。

代表成熟ECU架構的AUTOSAR經(jīng)典平臺（Classic Platform）將ECU從硬件到應用劃分為多個層次分明的組件，這一架構模式在中有著詳細闡述。與之形成對比的是，AUTOSAR自適應平臺（Adaptive Platform）已經(jīng)涵蓋了基于例如POSIX等先進標準的未來車輛ECU架構，其架構示意圖如圖所示。

在本章的最后部分，我們將介紹一種文化方法和一種結構方法。這些方法旨在助力汽車行業(yè)更好地落地實施技術方法，推動汽車行業(yè)更緊密地與信息技術（IT）開發(fā)及其工具鏈相融合，從而滿足軟件驅(qū)動型車輛架構日益增長的需求。

集中式高性能計算（HPC）電子控制單元（ECU）在設計過程中，必須充分考慮處理大量偶然數(shù)據(jù)所需的高計算能力。此外，鑒于車輛在其生命周期內(nèi)可能會通過空中下載（FOTA）方式持續(xù)更新功能，軟件驅(qū)動型車輛對計算能力的需求也將不斷攀升。為了在集中式ECU中高效地處理CPU密集型任務，硬件加速器成為不可或缺的關鍵組件。硬件加速器是專為特定任務量身定制的專用硬件，例如在計算機的圖形顯示領域就已得到廣泛應用。這些加速器能夠根據(jù)實際需求靈活開啟或關閉，從而顯著提高整體計算效率，減輕CPU的負載壓力。

隨著車輛開發(fā)中功能數(shù)量的持續(xù)增加以及新的CPU密集型技術的不斷引入，單核處理器已難以滿足日益增長的計算需求。由于功率耗散限制，CPU頻率的持續(xù)提高遭遇瓶頸[15]。因此，多核和眾核處理器被視為推動E/E架構集中化的關鍵力量。這類處理器能夠?qū)崿F(xiàn)任務分配的并行化處理，從而大幅增加可用的計算能力。多核處理器還支持時間上的干擾自由度，這在虛擬化以及在同一CPU上使用不同操作系統(tǒng)（如實時系統(tǒng)與服務器客戶端系統(tǒng)）方面具有重要意義，是保障系統(tǒng)安全性的關鍵因素。然而，與此同時，系統(tǒng)復雜性也會隨之增加，并且需要考慮與舊平臺的向后兼容性問題。為此，業(yè)界已研發(fā)出各種軟件機制和不同方法，旨在在遵循計算序列的同時實現(xiàn)核心的均衡負載分配，避免任務分配不當。盡管這些內(nèi)容在此不再深入展開，但值得進一步深入研究與探討。

-> 深入ECU層面：基礎軟件與虛擬化、中間件的作用

當我們將目光聚焦于ECU層面，并進一步向應用層靠近時，基礎軟件（BSW）的最低層——微控制器抽象層（MCAL），成為了備受矚目的關鍵環(huán)節(jié)。MCAL猶如一座橋梁，巧妙地使上層軟件層與主處理器及其片上外設（如通信模塊、存儲器、輸入/輸出（I/O）等）實現(xiàn)了分離。操作系統(tǒng)通過MCAL這一抽象層面與硬件進行交互，這一創(chuàng)新設計為程序員帶來了極大的便利，使他們能夠編寫與具體設備無關的軟件（SW）。正因如此，MCAL顯著提升了軟件在不同ECU（包括那些更靠近潛在中央主ECU的ECU）之間的可移植性，為汽車軟件的高效開發(fā)與靈活部署奠定了堅實基礎[4]。

高級駕駛輔助系統(tǒng)（ADAS）和信息娛樂系統(tǒng)在運行過程中，需要處理和傳輸海量的數(shù)據(jù)。在嵌入式ECU開發(fā)領域，傳統(tǒng)的基于時間驅(qū)動的操作系統(tǒng)（如AUTOSAR Classic）已逐漸觸及性能極限，難以滿足日益增長的復雜需求。而較新的、基于POSIX的AUTOSAR Adaptive標準則猶如一股清新的風，為汽車開發(fā)者帶來了全新的開發(fā)模式。它允許開發(fā)者以事件驅(qū)動、客戶端 - 服務器為導向的方式進行開發(fā)，因為自適應平臺支持在運行時動態(tài)鏈接服務和客戶端。這些獨特的特性使得ECU能夠輕松應對當前和未來車輛功能的復雜性與計算負載，為汽車智能化發(fā)展提供了強大的技術支持。然而，AUTOSAR Adaptive并不會取代AUTOSAR Classic，后者憑借其硬實時、時間關鍵且計算負載較低的優(yōu)勢，仍將在特定應用場景中發(fā)揮重要作用。

為了在同一個CPU中實現(xiàn)相關功能和應用的和諧共存，我們引入了集中化的又一關鍵推動因素——虛擬化。虛擬化技術如同一位神奇的魔法師，使得在同一硬件上運行多個操作系統(tǒng)成為可能，從而極大地增加了將兩個具有不同要求的ECU（例如，一個需要確定性行為，另一個需要非確定性行為）集中到同一硬件上的潛力，為汽車硬件資源的優(yōu)化利用開辟了新途徑。

在同一個CPU上并行執(zhí)行多個操作系統(tǒng)，這一宏偉目標的實現(xiàn)離不開虛擬機監(jiān)控器（Hypervisor）的助力。Hypervisor，也稱為虛擬機監(jiān)視器（VMM），它就像一位嚴謹?shù)墓芗遥瑢⒂布c虛擬機（VM）及其操作系統(tǒng)隔離開來。Hypervisor時刻監(jiān)控著相關VM的硬件需求，并根據(jù)實際需求精準管理硬件分配。Hypervisor主要分為兩種類型：類型1和類型2。類型1 Hypervisor，也稱為裸機Hypervisor，它直接與硬件交互，充當主機操作系統(tǒng)的角色，負責管理在其上運行的客戶操作系統(tǒng)的資源檢索。類型2 Hypervisor則作為應用程序在已有的主機操作系統(tǒng)上運行，通過主機為客戶操作系統(tǒng)請求資源，執(zhí)行純軟件虛擬化。同樣，虛擬化也需要借鑒多核處理的方法和模式，以確保干擾自由、內(nèi)存保護、符合ISO 26262標準的安全要求[20]，以及規(guī)范虛擬機邊界之間的通信。

-> 虛擬化與操作系統(tǒng)：對E/E架構集中化的深遠影響

在總結虛擬化和操作系統(tǒng)對E/E架構集中化的影響時，我們來到了從ECU硬件到應用層的中間件層面。中間件猶如一位默默的幕后英雄，將應用層與基礎軟件、操作系統(tǒng)和硬件抽象開來。它極大地提高了軟件組件（SWC）的靈活性，使軟件開發(fā)者能夠全身心地專注于功能實現(xiàn)，而無需為底層細節(jié)所困擾。智能中間件解決方案將成為現(xiàn)代車輛訪問信息技術（IT）領域服務乃至全球互聯(lián)網(wǎng)服務的關鍵推動因素。通過集成中間件，服務能夠在雙方之間得到正確翻譯和解釋，確保信息傳遞的準確無誤。雖然AUTOSAR Classic的時間驅(qū)動中間件稱為運行時環(huán)境（Runtime Environment），但AUTOSAR Adaptive則使用稱為ARA的中間件來處理服務器和客戶端之間的通信，展現(xiàn)了不同架構下中間件的獨特魅力。

-> 微服務與容器化：構建靈活、可擴展的汽車軟件架構

在此背景下，我們愈發(fā)清晰地認識到，為了實現(xiàn)ECU的集中化和虛擬化，并確保軟件驅(qū)動型車輛的互聯(lián)互通，智能中間件解決方案是必不可少的。這種抽象化還需要軟件組件（SWCs）以靈活設計且具有明確定義接口的形式在應用層得到有力支持。為了降低復雜性并提高靈活性，我們可以采用“分而治之”的范式，通過設計解耦的微服務來構建應用。每個微服務都專注于處理較小的任務，猶如一顆顆精密的齒輪，相互協(xié)作，共同推動整個系統(tǒng)的運轉(zhuǎn)。微服務增強了功能和軟件架構的可擴展性和可交換性，為汽車軟件的持續(xù)進化提供了強大動力。通過編排，微服務可以在不同的應用中實現(xiàn)復用，進一步提高開發(fā)效率和軟件質(zhì)量。

將微服務與其運行所需的一切（如系統(tǒng)庫、配置、工具和運行時環(huán)境）組合在一起，就創(chuàng)建了一個容器。容器代表了一個獨立的部署單元，它總體上支持DevOps實踐中的持續(xù)集成/持續(xù)部署（CI/CD）。容器可以視為一種統(tǒng)一的技術方法，從一開始就設計出獨立于未來硬件或宿主機的應用。它使應用在中央主ECU上具有更好的可遷移性，并在保持微服務原則的同時管理日益增長的復雜性，為汽車軟件的快速迭代和部署提供了有力保障。

-> 汽車行業(yè)與IT領域：工作方法與組織結構的碰撞與融合

盡管所介紹的技術方法在IT領域已經(jīng)確立并得到廣泛應用，但汽車行業(yè)才剛剛開始在汽車日益數(shù)字化的背景下引入這些方法。文化和結構方法可以增強將所有介紹的技術方法付諸實踐的潛力。在比較汽車行業(yè)公司與IT領域公司的工作方法和組織結構時，可以發(fā)現(xiàn)兩者存在顯著差異。在汽車行業(yè)，目前主要遵循V模型和垂直結構進行開發(fā)，這種模式注重流程的嚴謹性和系統(tǒng)的完整性，但在應對快速變化的市場需求時可能顯得較為僵化。而在IT領域，DevOps和水平結構占主導地位，強調(diào)快速迭代、靈活開發(fā)和高效協(xié)作，能夠迅速適應市場變化。

顧名思義，DevOps通過一系列技術、方法和文化方法將開發(fā)與運維緊密結合。其目標是加快開發(fā)、測試和發(fā)布過程，以提高軟件質(zhì)量。通過將開發(fā)與運維融合，運營商和/或客戶的反饋可以直接反饋到開發(fā)中，形成一個無限循環(huán)，從而實現(xiàn)持續(xù)集成/持續(xù)部署（CI/CD）的原則。由于未來的車輛將越來越依賴軟件，并有可能按需更新單個功能，因此汽車行業(yè)的工作方法將向DevOps演進，以適應汽車智能化發(fā)展的新趨勢。目前尚不清楚DevOps是否會取代V模型，或者兩者是否會共存，亦或是未來汽車開發(fā)中會采用兩者的結合，這需要汽車行業(yè)在實踐中不斷探索和驗證。

此外，根據(jù)康威定律，組織結構（尤其是溝通結構）會影響所開發(fā)系統(tǒng)的架構[3]。將這一原理應用于車輛的E/E架構，意味著E/E架構反映了公司的溝通結構。由于當前車輛的E/E架構仍以垂直方向為特征，根據(jù)康威定律，垂直的組織結構可能是其中一個根本原因。換句話說，為了推動E/E架構的集中化，必須集中溝通和組織結構，打破部門之間的壁壘，促進信息的自由流通和高效協(xié)作，為汽車E/E架構的創(chuàng)新發(fā)展創(chuàng)造有利條件。

-> 功能分離與系統(tǒng)方法：為汽車E/E架構集中化提供決策支持

考慮到之前討論的技術方法，在建立功能集中化的系統(tǒng)方法之前，必須首先將系統(tǒng)及其功能分解為單個組件。下一章將定義一個功能分離的概念，為后續(xù)的系統(tǒng)開發(fā)提供清晰的指導。在此基礎上，將開發(fā)一個系統(tǒng)方法，該方法將技術解決方案應用于抽象的功能，旨在評估集中化的潛力。這種系統(tǒng)方法將幫助系統(tǒng)設計師和功能工程師在決定如何在系統(tǒng)內(nèi)分配功能時做出明智的決策，重點關注當前汽車開發(fā)中呈現(xiàn)的趨勢和挑戰(zhàn)，為汽車E/E架構的集中化發(fā)展提供堅實的理論支撐和實踐指導。

ECU 基礎與 I/O 連接方式剖析

每個電子控制單元（ECU）或控制器項目均以硬件（HW）為基石。中央處理器（CPU）和微控制器單元（MCU）作為硬件的核心組成部分，必須具備相應的計算能力和控制邏輯，以支撐整個系統(tǒng)的運行。這些硬件設備將作為操作系統(tǒng)的運行載體，操作系統(tǒng)則肩負著將來自軟件組件（SWCs）的任務合理分配到硬件內(nèi)核和核心上的重任，同時還要對輸入/輸出（I/O）電路進行監(jiān)控與操作。這些 I/O 電路作為硬件的基本構成元素，充當著執(zhí)行器或傳感器等 I/O 設備與處理單元（負責評估和控制邏輯）之間的橋梁。

在后續(xù)的步驟中，I/O 可以采用集中式或分布式的方式連接到處理 ECU 上。因此，在抽象方法的考量中，需要兼顧直接的模擬 I/O 信號線（集中式）以及各類數(shù)字通信協(xié)議，如 LIN、CAN、以太網(wǎng)，甚至基于 IEEE 802.11 標準的無線通信（分布式）。集中式 I/O 的顯著優(yōu)勢在于能夠有效減少 ECU 的數(shù)量。由于無需網(wǎng)關進行數(shù)據(jù)轉(zhuǎn)發(fā)，信息將直接由一個功能更為強大、規(guī)模更大的集中式主 ECU 進行處理。然而，集中式 I/O 也并非十全十美，它存在一些潛在的劣勢，這些劣勢將在后續(xù)的討論部分詳細闡述。

基于上述分析，我們所選擇的四個基本組件——硬件（HW）、軟件（SW）、I/O 信號線和 I/O 通信（COM），已經(jīng)足以對功能進行全面抽象，從而為評估功能集中化的潛力提供有力支持。圖 展示了這些基本組件的通用示意圖，這些組件將基于現(xiàn)代混合動力和電動汽車中廣泛應用的溫度電流降額功能進行驗證，以檢驗其在實際應用中的有效性和可行性。

功能集中化的方法學闡述

該方法學方法以面向領域的 E/E 架構為起點，該架構代表了當前的技術發(fā)展狀態(tài)。通過盡可能多地將邏輯集中到域控制器中，域控制器將逐步向中央主計算機演變。在理想情況下，最終僅保留智能執(zhí)行器和傳感器，實現(xiàn)系統(tǒng)的高度集成。在進一步的闡述中，我們可以開發(fā)一套系統(tǒng)方法，將各個域的邏輯集中到跨域或一個中央計算機中，從而使域控制器僅承擔簡單的翻譯區(qū)域網(wǎng)關控制器的功能，簡化系統(tǒng)架構，提高系統(tǒng)的整體效率和可靠性。

該活動圖旨在有效管理當前汽車行業(yè)面臨的趨勢和挑戰(zhàn)，推動系統(tǒng)從分散且分布式的面向領域功能架構向功能集中化邁進。在實施過程中，必須對每個域的功能進行細致評估，以便在域 ECU 本身內(nèi)部容納盡可能多的功能，最終實現(xiàn)向中央主計算機的演進。

方法學方法的驗證過程

為了驗證 UML 活動圖中所示的方法學方法，我們選取了混合動力和電動汽車中典型的溫度電流降額功能作為案例。該功能基于充電口內(nèi)傳感器的溫度數(shù)據(jù)，對充電電流進行調(diào)節(jié)，以防止因過熱而導致的損壞和傷害。根據(jù) ISO 26262 標準，該功能具有 ASIL B 評級，其安全性和可靠性對于車輛的正常運行至關重要。這些信息對于深入討論集中化潛力具有重要的參考價值。

主要邏輯可分為兩部分。第一部分通過電路對溫度傳感器進行評估，并提供交流（AC）和直流（DC）引腳的溫度值。根據(jù) IEC 62196 標準，必須確?？捎|摸的非金屬部件的最大溫度不超過 85°C，因此這一評估環(huán)節(jié)至關重要。第二部分負責處理溫度值并計算可抽取的潛在電流。降額功能可視為一種質(zhì)量性能功能，旨在優(yōu)化充電過程。充電也可以以連續(xù)的最大電流進行，但這樣可能會導致溫度迅速達到 85°C 的閾值，即使車輛的目標充電狀態(tài)尚未達到，也需要停止充電。因此，降額功能應智能地調(diào)節(jié)電流，使充電過程不會直接運行在閾值并導致停止，而是以較低的電流繼續(xù)充電，以達到最佳的時間跨度，實現(xiàn)高效、安全的充電。

由于與傳感器和相應電路存在緊密的連接和依賴關系，主要邏輯的第一部分無法自由移動。然而，根據(jù)內(nèi)容，主要邏輯的第二部分可以設計為一種微服務。它具有明確的輸入（如溫度值）和明確的輸出（即基于其計算的實際最大電流），這一特性使得 SWC 或微服務溫度電流降額功能具有高度的靈活性和位置無關性，便于在不同的系統(tǒng)架構中進行部署和調(diào)整。

溫度電流降額功能原本分配給了三個不同的 ECU。按照 UML 活動圖的指引，上述主要邏輯的第二部分可以移動到更接近域控制器的 ECU 中。在第一步中，這將是 ECU EVCC。傳感器的 I/O（包括其電路）通過從傳感器到 EVCC 的直接模擬信號線進行集中化，從而減少了不必要的硬件組件和通信線路。這樣，功能本身就不再需要 ECU Inlet，實現(xiàn)了功能的優(yōu)化整合。然而，這僅適用于該特定功能，因此一般不能直接移除 ECU Inlet。這也是為什么必須對域中的每個功能 x 執(zhí)行 UML 活動圖的原因，因為集中化潛力最小的功能會限制組件的移除。功能的新架構如圖 中從上數(shù)第二個所示，實現(xiàn)了初步的功能集中化。

在面向區(qū)域的 E/E 架構方面更進一步，通過將主要邏輯的第二部分移動到應演變?yōu)橹醒胗嬎銠C的域 ECU 中，ECU EVCC 將轉(zhuǎn)換為一個簡單的區(qū)域網(wǎng)關 ECU。區(qū)域網(wǎng)關 ECU 現(xiàn)在作為一個簡單的智能傳感器，為域控制器進行監(jiān)控和翻譯，實現(xiàn)了數(shù)據(jù)的高效傳輸和處理。在區(qū)域網(wǎng)關 ECU 下方，可以放置進一步的傳感器和執(zhí)行器，這些傳感器和執(zhí)行器將由域控制器進行統(tǒng)一監(jiān)控和處理，進一步優(yōu)化了系統(tǒng)架構。新的功能架構如圖的第三行所示，實現(xiàn)了更高程度的功能集中化。在 UML 圖的最后一步中，甚至區(qū)域網(wǎng)關 ECU 也將被移除，通過再次將 I/O 直接集中到其域控制器中，實現(xiàn)了功能的全面集中化。這導致電路被移入域控制器，同時也減少了通信線路的數(shù)量，進一步簡化了系統(tǒng)結構。這種最集中的功能架構如圖 的最后一行所示，達到了功能集中化的理想狀態(tài)。由于溫度電流降額功能的進一步集中化已不可能，接下來將對不同變體的優(yōu)勢、劣勢和挑戰(zhàn)進行深入討論。

結論

在本文中，我們提出了一種方法學方法，旨在支持系統(tǒng)和功能工程師對E/E架構進行集中化。我們收集、研究了當前研究中的技術解決方案，并將其整合到一個UML活動圖中，通過該圖可以制定和集中化不同的功能設計。然而，集中化并不能被視為E/E架構中每個功能的通用解決方案。一般來說，集中化將提高未來技術（如高級駕駛輔助系統(tǒng)（ADAS）或信息娛樂系統(tǒng)）的可管理性，并降低其復雜性，這些技術以大量的代碼行和數(shù)據(jù)為特征。否則，這些技術在不久的將來可能難以管理。

然而，在集中化功能時也存在劣勢，特別是在涉及傳統(tǒng)功能以及不需要高計算能力或大量數(shù)據(jù)的功能時，必須對這些劣勢進行詳細闡述。