概要

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

電子電氣架構演進

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

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

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

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

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

什么是容器化？

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

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

容器簡化管理

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

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

可直接遷移的設計

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

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

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

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

架構演進的考慮因素

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

硬件注意事項包括：

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

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

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

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

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

向云就緒轉型的軟件注意事項包括：

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

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

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

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

審核編輯：湯梓紅