電子電氣架構(gòu)演進和發(fā)展趨勢

概要

根據(jù)麥肯錫公司的報告，汽車行業(yè)的軟件和電子技術(shù)已經(jīng)取得了重大突破。隨著自動駕駛、互聯(lián)汽車、動力系統(tǒng)的電氣化以及共享出行（ACES）的破壞性力量的推動，軟件定義的車輛架構(gòu)正迅速成為現(xiàn)實。該公司預測，到2030年——在三到四代車輛中，70%的車輛將擁有軟件定義的架構(gòu)。因此，整個汽車產(chǎn)業(yè)鏈上的企業(yè)現(xiàn)在必須開始充分利用這一潛力。

電子電氣架構(gòu)演進

在2017年之前，傳統(tǒng)驅(qū)動的車輛以離散的電子控制單元（ECUs）及其分布在整個汽車中的嵌入式軟件為特征。這些來自各個供應商的部分基本上由OEM組裝，從軟件的角度來看幾乎沒有增值。如果ECU出現(xiàn)故障或需要更新，就需要經(jīng)銷商的合格工程師進行手動更換。

從2017年開始，OEM們已經(jīng)開始考慮諸如車身控制、動力系統(tǒng)和信息娛樂等領(lǐng)域，并采用了一定程度的計算集中化。這種領(lǐng)域概念現(xiàn)在已經(jīng)發(fā)展成為一種跨領(lǐng)域的物理區(qū)域基礎(chǔ)的電子/電氣（E/E）架構(gòu)，該架構(gòu)將大量離散的ECUs高度集成，以利用更少的、本地化的、性能更高的計算機系統(tǒng)。

這種轉(zhuǎn)變背后的原因是為了降低布線、重量和復雜性，同時提高效率。但是，通過在軟件中定義更多元素來完成更多工作的能力為日益增加的復雜性敞開了大門。OEM繼續(xù)將其分區(qū)架構(gòu)延伸至服務器化，進一步通過在更大的高性能計算(HPC)單元上集成更多軟件來減少計算單元的數(shù)量。

到2030年的云原生就緒的汽車將繼續(xù)在車上執(zhí)行許多關(guān)鍵的實時功能，如防抱死制動系統(tǒng)代碼。云端可以通過公有云或私有云設(shè)置來提供額外服務，如根據(jù)當前位置或目的地為可用停車位提供路線指導。

電子/電氣架構(gòu)已經(jīng)取得了長足的進步，開始使用敏捷開發(fā)模型。在未來幾年內(nèi)，OEM將采用一種軟件開發(fā)和IT運維(DevOps)類型的環(huán)境，實現(xiàn)持續(xù)集成、持續(xù)測試和持續(xù)交付。這個能力的重任將由容器承擔。

什么是容器化？

容器化是模塊化的進階，其核心思想是通過檢查多個軟件系統(tǒng)來識別可復用的區(qū)域。這些區(qū)域隨后被隔離成不同的模塊，以實現(xiàn)清晰的功能劃分和問題定位。容器化將包含操作系統(tǒng)（OS）庫和依賴項的模塊打包，使得在任何硬件計算環(huán)境中都能夠一致地運行輕量級可執(zhí)行文件。

云計算技術(shù)的集成到車輛中，旨在提供全新的功能、服務和體驗。為了實現(xiàn)這一目標，首先需要通過抽象、模塊化和容器化等手段來消除現(xiàn)有的電子控制單元（ECUs）。這種集成方式能夠有效地提高系統(tǒng)的靈活性和可擴展性，為車輛的功能升級和創(chuàng)新提供了堅實的基礎(chǔ)。

容器簡化管理

傳統(tǒng)的嵌入式系統(tǒng)中的軟件管理是一項代價高昂的任務，可能需要更新幾十個軟件解決方案。這些解決方案通常是單體的，具有專有性質(zhì)，因此確保它們在車輛中可靠工作是一個巨大挑戰(zhàn)。

相比之下，由Open Container Initiative (OCI)支持的自包含包是一個容器，它使部署運行時與平臺無關(guān)。OCI指定了容器如何從實驗室移動到公共或私有容器注冊表，并在安全框架內(nèi)為云就緒車輛提供訪問。最后，需要一個工具來管理從云到車輛邊緣的容器交付。廣泛用于云軟件開發(fā)的Kubernetes開源容器編排系統(tǒng)是此步驟的明確選擇。因此，容器化是一種允許輕松管理各個面向服務的代碼塊的模型。由于超過60%的后端開發(fā)人員已經(jīng)使用容器來構(gòu)建和部署軟件，它是軟件架構(gòu)的首要邏輯和必要元素。

可直接遷移的設(shè)計

傳統(tǒng)ECU設(shè)計方法正面臨日益嚴峻的挑戰(zhàn)，難以為繼。以現(xiàn)有的自動列車開放式系統(tǒng)架構(gòu)（AUTOSAR）環(huán)境為例，實時環(huán)境（RTE）、基本軟件（BSW）和操作系統(tǒng)層都位于ECU硬件之上。每個功能特性，如駕駛員疲勞識別、車道偏離警告或速度表，都是獨立于ECU實現(xiàn)的單一模塊。這種架構(gòu)由于其僵化的方法使系統(tǒng)難以維護和升級，與朝著云原生就緒車輛發(fā)展的進步格格不入。

在云原生就緒環(huán)境中，采用“直接遷移”或重新托管的方法可以降低遷移過程所固有的工作量和成本。這種方法只需將一個完整容器中的精確應用程序副本從其傳統(tǒng)環(huán)境或云端遷移到基于多核SoC的高性能計算（HPC）的全新集成環(huán)境中即可。

工程師可以通過兩種方式之一來實現(xiàn)“直接遷移”。他們可以提升打包在容器中的AUTOSAR堆棧，并使用運行在操作系統(tǒng)上的容器引擎進行部署，該容器引擎位于托管型Type 1虛擬機監(jiān)視器上。或者，可以將應用程序、操作系統(tǒng)和虛擬機監(jiān)視器容器化，以使運行環(huán)境更加可預測。

下圖展示了直接遷移設(shè)計的第一個優(yōu)勢，即軟件的可重用性。在舊的單體式軟件架構(gòu)中，存在顯著的軟件組件之間的依賴關(guān)系。這意味著當一個組件中的代碼發(fā)生更改時，可能需要在整個代碼庫中進行級聯(lián)更新。然而，面向服務的架構(gòu)的容器化方法減少了這種依賴關(guān)系，并將代碼更改限制在相關(guān)組件中。這種方法使得軟件更加靈活和可擴展，從而提高了開發(fā)效率和軟件質(zhì)量。

架構(gòu)演進的考慮因素

硬件和軟件方面的考慮因素會影響落地的類型和變更的速度。

硬件注意事項包括：

成本：現(xiàn)有ECU中的微控制器相對SoC來說很便宜。盡管所需的HPC單元更少，但仍需仔細評估所需的競爭力與可能造成的成本之間的權(quán)衡。

功耗：考慮到動力總成的電氣化，比較大量微控制器（功率較低，效率較低）與較少SoC（功率較高，效率較高）的總功耗很重要。

I/O可用性：較少的HPC單元可能意味著比所需的I/O更少。盡管硬件供應商正在解決這個問題，但在選擇SoC時仍需考慮此問題。

供應鏈：隨著芯片供應現(xiàn)在成為一個挑戰(zhàn)，理解維持現(xiàn)有供應商關(guān)系而不是尋找承諾新功能的新的HPC供應商的影響是至關(guān)重要的。

布線：這是汽車行業(yè)在設(shè)計變更時必須考慮的一個關(guān)鍵因素。例如，將車門作為一個獨立的區(qū)域并為其配備HPC（高性能計算機）系統(tǒng)可能會帶來諸多益處。這樣一來，不僅可以避免為電動車窗、車門鎖以及揚聲器和燈光分別布設(shè)額外的線纜，還能實現(xiàn)更加簡潔、高效的整車設(shè)計。

向云就緒轉(zhuǎn)型的軟件注意事項包括：

模塊化：在考慮向云就緒轉(zhuǎn)型時，必須仔細評估遺留軟件是否具備模塊化的特性。如果無法實現(xiàn)模塊化，可能需要將整個軟件整體移入容器中進行部署。

代碼可用性：在進行代碼遷移時，必須認識到遺留代碼的可用性可能存在一定的限制。過時的功能僅存在于二進制文件中，這可能會對未來的靈活性產(chǎn)生一定的影響。因此，在進行這種轉(zhuǎn)換時，需要權(quán)衡當前額外付出的努力與未來靈活性的損失。

開銷：面向服務的架構(gòu)（Service-oriented architecture，SOA）在軟件層數(shù)方面具有更多的層次。管理程序沒有額外的開銷，但為了滿足嚴格的時序約束，必須考慮實時操作系統(tǒng)（Real-time Operating System，RTOS）所帶來的額外開銷。

成本：在進行面向服務的架構(gòu)遷移時，需要充分考慮變革所需的成本。這包括時間和工作的投入，以及可能產(chǎn)生的額外費用。同時，還需要根據(jù)緊迫的截止日期和其他限制因素來評估整個變革的成本，并在決策過程中進行權(quán)衡和調(diào)整。

審核編輯：湯梓紅