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

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

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

3、 跨領(lǐng)域和面向區(qū)域的E/E架構(gòu)

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

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

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

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

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

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

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

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

5、集中化的技術(shù)方法

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

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

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

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

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

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

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

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

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

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

-> 虛擬化與操作系統(tǒng)：對(duì)E/E架構(gòu)集中化的深遠(yuǎn)影響

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

-> 微服務(wù)與容器化：構(gòu)建靈活、可擴(kuò)展的汽車(chē)軟件架構(gòu)

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

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

-> 汽車(chē)行業(yè)與IT領(lǐng)域：工作方法與組織結(jié)構(gòu)的碰撞與融合

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

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

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

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

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

ECU 基礎(chǔ)與 I/O 連接方式剖析

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

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

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

功能集中化的方法學(xué)闡述

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

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

方法學(xué)方法的驗(yàn)證過(guò)程

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

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

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

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

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

結(jié)論

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

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