概要

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

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

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

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

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

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

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

什么是容器化？

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

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

容器簡(jiǎn)化管理

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

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

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

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

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

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

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

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

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

硬件注意事項(xiàng)包括：

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

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

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

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

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

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

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

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

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

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

審核編輯：湯梓紅