摘要：在過去的二十年中，汽車軟件的需求和應用急劇增長，隨之復雜性急劇上升?，F有技術和框架不足以應對這種復雜性，現在很明顯，汽車制造商（OEM）必須重新考慮他們生產車輛的方式以及車輛本身的生命周期。通過將重點放在軟件上，OEM可以在車輛整個生命周期中實現許多新的應用用例，并打開一個充滿機遇的新世界。博世及其子公司ETAS在過去幾十年中一直處于汽車創新的前沿。

通過他們的專業知識和與汽車制造商的密切關系，他們正在親身經驗體驗軟件復雜性的增加和開發概念的改變。本文介紹為了賦能新一代 “軟件定義汽車 “，OEM所必須采取的改變其當前技術棧的步驟。

介紹

在過去的二十年中，軟件組件在塑造汽車行業方面發揮了主導作用。汽車制造商（OEM）正面臨著新一代的買家，他們希望擁有一輛可以滿足所有新愿望的個性化和互聯的汽車，軟件甚至正在成為OEM的決定性區別和銷售論據。根據波士頓咨詢集團（Boston Consulting Group）的數據，目前汽車行業90%的創新來自軟件[1]。同樣，據麥肯錫[2]預計，汽車電子和軟件市場的增長速度將遠遠超過整個汽車市場。駕駛員輔助系統的基于傳感器的環境檢測和廣泛的信息娛樂產品只是客戶期望他們的車輛所具備的軟件定義功能中的兩個示例。

在未來，實現更高級別的自動駕駛功能、提供即時錯誤修復并持續提供新功能將成為新的規范。后者似乎很熟悉，因為智能手機市場經歷了一場類似的革命[1]，現在已經成為客戶數字生活的中心。車輛多樣性和固有管理復雜性的增加，要求新的軟件和硬件的開發方式。因此，在軟件和硬件開發解耦的情況下，需要從傳統的V模型向持續開發和集成的轉變。盡管汽車制造商需要進行大量的初始投資來開發和建立新的電氣和電子（E/E）架構及其軟件平臺，但預計他們每年將避免在測試、集成和維護多個領域獲得160億美元的節省[3]。

現有的方式將軟件引入車輛有明顯的主要局限性。OEM依賴分布式E/E架構和整體的軟件架構，由于開發新功能以及更新現有協議棧所需的復雜度和工作導致了測試、集成和維護成本很高[3]。由于缺乏速度和巨大的開發成本，汽車設備制造商無法快速進行試驗和創新。因此，這限制了他們滿足單個客戶需求的能力，從而限制最大限度地利用車輛的整個生命周期的價值。

很明顯，當前的開發理念不再合適，行業需要轉向以軟件為中心的方法[3]。基于軟件的功能需要“可靠、快速反應并在車輛使用壽命內快速更新”[1]。通過重新思考汽車的生產方式，將以軟件為中心，汽車設備制造商可以提高其客戶忠誠度，并在其生命周期內增加汽車的價值。例如，特斯拉Model S在購買七年后比其競爭對手更保值，這歸功于其始終最新的軟件協議棧和功能更新[1]。

本文旨在涵蓋技術解決方案，使原始設備制造商能夠成功地從“耗費大量精力和成本的軟件創新和更新”轉向“自動、連續、快速、輕松地將任何數量的軟件功能交付給任何期望的車輛”。

二

成功轉向軟件定義車輛（SDV）意味著什么？

為了釋放SDV的全部潛力，必須通過在云端和車輛中運行的合適的工具和軟件解決方案來理解和掌握幾個挑戰。

2.1硬件和軟件解耦——SDV的基礎

在過去的幾十年中，汽車設備制造商主要從不同供應商處采購電子控制單元（ECU），作為一個組合的硬件-軟件系統，以功能為中心，并承受較高的成本壓力。因此，系統級的集成工作隨著每一個新的子系統呈指數增長，計算資源在預生產定義的功能范圍內得到優化，開發工具鏈專門針對OEM、供應商和功能特定需求進行項目實施。因此，實現的功能代碼從一個車輛項目轉移到另一個幾乎是不可能的。

同時，汽車行業一直面臨著車輛軟件功能數量和交付頻率的增加[1,3]，涉及數量不斷增加的ECU。這種復雜性導致了集成工作的泛濫，成本飆升，項目持續時間更長。麥肯錫表示，過去十年，軟件復雜性增長了4倍，而開發生產力僅增長了1.0至1.5倍[4]。

因此，必須采取三項主要行動：

減少ECU的數量，同時增加計算資源，以降低硬件復雜性并提高其性能。

協調OEM內部的基礎軟件及其底層開發工具鏈，以實現跨車輛平臺的車輛功能兼容性。

引入開放接口和面向服務的體系結構，以簡化OEM、其供應商和開發人員之間的協作和集成。

因此，OEM目前引入了硬件和軟件生命周期的解耦，允許將通常分布在幾個區域ECU和車輛計算機內的多個ECU上的功能捆綁在一起[2,5]。車輛中的這種新E/E）架構簡化了功能部署，同時需要更高的計算資源和工具來支持管理依賴性和變量。

2.2選擇標準化中間件

集中式E/E架構正在推動平臺軟件方面的大規模技術變革，需要根據領域的不同而擴展一系列功能。AUTOSAR Classic[6]為安全和硬實時ECU提供了全面的解決方案。該標準在汽車行業被廣泛接受和采用，涵蓋多個網絡的診斷和安全通信等服務，通常是發動機控制器、變速器ECU等所必需的。

隨著車載計算機的引入，另一個標準與經典一起被定義，這就是AUTOSAR自適應標準[6]。盡管共享了大部分基本原則，但目標卻截然不同，因為AUTOSAR自適應旨在為基于POSIX的ECU提供一組集群式服務，其微處理器能夠執行車輛范圍的功能，以增強駕駛員體驗。

最近，LINUX（獨立或與信息娛樂集成）上非安全通用計算環境的采用受到了越來越多的關注。在這個稱為車輛邊緣，像容器化這樣的云原生方法針對汽車用途進行了優化。這使得能夠進一步簡化和加速車輛應用程序的集成，同時通過隔離實現封裝和安全性。

當涉及到支持汽車中最先進的技術功能，轉向自動駕駛時，汽車操作系統（AOS）為ADAS功能引入了一個完整的新開發模式，涵蓋了整個開發周期以及實現ADAS功能的中間件平臺軟件。領先的汽車原始設備制造商正利用其非常有效的方法采用此類技術。

2.3使用云開發工具鏈簡化和加快開發速度

在理想的世界中，開發人員有一個隨時可用的開發環境，支持他們檢查更改并從自動化流水線系統收集反饋。經過少量調整和迭代后，他們一直在開發的功能就準備好發布了。如果他們是由分布式開發團隊組成的更大組織的一部分，那么他們將連接到正確的代碼庫，所有開發人員將在一個共同的協作平臺中同步。最后，作為流水線系統管道的一部分，自動生成認證和其他發布手續所需的文檔。

然而，汽車行業的現實情況卻大不相同。開發人員將60%以上的時間用于維護開發環境、手動執行大量測試、處理文檔（包括其他手續）以及最終發布代碼。

汽車云開發工具鏈和協作平臺旨在通過結合汽車領域的專業知識以及云技術提供的可能性。通過使用標準化接口，現在可以集成第三方工具。這使開發人員能夠專注于創建新內容，而不是維護現有工具。由于自動化流水線系統，開發測試和反饋周期可以加快。云技術還為OEM內部不同團隊及其供應商之間的協作平臺提供了基礎。

2.4快速輕松地開發車輛應用程序

來自終端消費者和高性能軟件驅動的競爭對手的壓力越來越大，迫使原始設備制造商提高其軟件交付性能。這種性能可以通過幾個關鍵性能指標（KPI）來衡量，如功能交付周期、部署頻率、恢復時間或更改失敗百分比。

通過選擇經過驗證的云原生模式并將其用于汽車，可以顯著減少軟件開發持續時間。例如，通過將容器隔離、開發人員為中心的工具鏈和車輛API相結合減少軟件流程負載。這種方法為從ECU上的ASIL環境（具有不同的安全等級）到車輛計算機上的質量管理（QM）環境（沒有安全要求）的業務邏輯轉變打開了大門。

從車載軟件的角度來看，需要一個異構的車輛邊緣QM環境，以便在車輛內便捷開發、部署和運行應用程序。為了加快開發，開發者商不必履行任何與安全相關約束。相反，運行環境與基礎E/E和安全架構相結合，確保車輛始終處于安全狀態。

此外，這種方法在軟件人才招聘方面帶來了進一步的好處，汽車行業在聘請足夠熟練的開發人員以C或C++等編程語言進行經典汽車軟件開發方面面臨越來越大的困難。通過上述現代軟件開發方法，OEM擁有的或第三方開發人員能夠使用他們選擇的現代編程語言開發基于容器的應用程序，并專注于差異化的業務邏輯，而不是處理安全問題和汽車特定流程。

2.5虛擬測試軟件

原始設備制造商面臨的一個關鍵問題是軟件開發過程即將結束時的“大爆炸”集成，其中一些問題被發現，導致車輛生產延遲。

對對于車輛的開發，有不同的角色。每一個都有不同的測試關注點。功能開發人員對底層協議?；?a target="_blank">操作系統不感興趣，但他們希望了解他們對功能KPI（針對ASIL）產生的影響。軟件集成商希望驗證功能增量（快速反饋回路），而無需運行在基于硬件的設置。安全工程師希望檢測軟件中的異常和弱點。測試工程師希望能夠盡早開始（前置）驗證所有功能。

更重要的是，需要基于不同版本的軟件進行回歸運行測試以實現可比性，即執行不同代碼版本的重復運行，并檢查它們是否導致相同（確定性）結果輸出。一旦報告了現場錯誤，就需要在實驗室（電子取證）重現情況。

面臨的挑戰在于建立一個足夠模塊化的測試解決方案，以支持所有用戶，無論在哪個開發階段，在這種情況下，以下能力是效率的重要標準：

加快測試，例如，避免等待幾天來完成回歸測試

自動化測試，例如，在后臺進行實際測試時更改配置并獲得反饋。

SDV方法允許獨立于硬件的可用性來解決這些問題。上述用例和角色視角清楚地表明，虛擬測試解決方案需要

模塊化和標準化，

適用于自動化（無頭，CI-CD-CT），

可以在云中進行擴展，以按需處理回歸峰值，從而優化成本。

因此，OEM可以從旨在解決這些需求的解決方案中受益，該解決方案采用模塊化和標準化的云虛擬測試解決方案，以實現高效開發，并向第三方供應商開放。

2.6在影子模式下采集現場數據

在不可能指定和驗證所有駕駛或環境情況（例如，“開放環境”或“開放世界”問題）的所有系統中，良好的確認和驗證（V&V）策略會增加很高的價值。

影子模式是這種V&V策略的重要組成部分。新開發的數據驅動功能或算法在真實條件下在目標環境中執行，以獲得“真實世界”輸入數據。影子功能不會主動控制駕駛系統，而是以靜音模式運行，并通過使用可配置的基于AI的過濾器和觸發條件從系統收集相關數據。功能、過濾器和條件通過OTA部署到一個系列車隊。

而收集的輸出數據則通過OTA傳送回云后端進行分析和進一步處理。

2.7大規模部署和管理軟件

軟件和硬件生命周期的為SDV建立一個連續的軟件開發和部署過程。車輛因此能夠不斷地適應其當前的需求。結合部署個性化車輛應用的能力，現場硬件軟件組合的多樣性使每輛車都獨一無二。數字維修也是如此：預計每輛車每年會更新數百次大量電子部零件、應用程序和服務。因此，SDV對靈活更新的需求將大幅增加。

傳統的OTA更新解決方案需要大量的手動工作來創建更新包（內在依賴關系管理）和管理活動。這種繁瑣的方法在當今車輛中跨異構軟件域管理更新時已經顯示出了局限性。因此，現有的解決方案不再適應來處理由于SDV所需的軟件更新數量和種類不斷增加帶來的挑戰。

為了克服這些挑戰，易特馳正致力于下一代OTA更新解決方案，該解決方案的靈感來源于云原生模范式[7]。基于聲明性方法[8]，授權車輛單獨識別其必須執行哪些操作（例如，“下載”、“安裝”、“更新”、“刪除”）以達到預期的狀態。

下一代OTA更新帶來以下好處：

通過上下文感知流水線并通過應用基礎設施即代碼[9]原則，自動生成和驗證車輛的各個預期狀態，

減少云后端的量和依賴性管理工作，

減少通過移動網絡傳輸并存儲在云中的數據量，

通過統一的車載更新API對所有車載域進行更新，如Linux/QNX OS、AUTOSAR經典/自適應中間件和應用程序、Container/AAAOS框架和應用程序以及ADAS/AD系統。

2.8從現場正確的數據中提取、分析、學習和改進

在“真實世界”條件下從現場車輛和設備收集的數據是各種用例的重要來源。例如，來自連接車輛的診斷數據用于檢測和解決質量問題，旨在減少召回活動和軟件故障?；趥鞲衅鞯沫h境檢測依賴于雷達、激光雷達或攝像頭，正被用于ADAS/AD功能的背景下的數據驅動開發。

然而，通過從車輛中收集數據，必須在收集不必要的數據和冒著丟失有價值的數據之間進行權衡。前者可能導致昂貴的流量、存儲和處理成本，但后者可能導致缺乏適當決策所需的相關數據。由于正確的權衡在很大程度上取決于用例，OEM應在車輛外部上有一個靈活的數據通道，以便在需要時僅收集相關數據。

除此之外，數據不僅來自現場，還來自各種來源。為了充分利用其價值，必須將收集的數據提供給公司在世界各地的開發團隊，甚至是其它公司的開發團隊，例如從OEM到Tier 1。因此，需要解決的挑戰有兩個方面：1.為數據共享創建法律基礎的組織基礎；2.建立接口和工具的技術基礎，以方便提取、處理和分析車輛現場數據。

在這種情況下，成功的基礎的關鍵標準是：

可擴展性和資源效率，其中集中式的一次性集成實現了針對多個用例快速載入不同的數據源

標準化，以便轉化來自不同來源的異構數據

卓越運營，依靠可擴展的全球數據基礎設施來確保數據可用性。

2.9遵循法規和標準

最近，汽車行業很少有法規和標準受到關注。在這方面最需要強調的是描述車輛軟件更新要求的第156號UNECE法規[10]。特別是OEM需要提供“軟件更新管理系統（SUMS）”正常運行的證據。SUMS是一種系統化方法，它定義了組織過程，以符合軟件更新管理和部署的要求。這種方法：

解決軟件更新是否會影響任何已有的系統，

使用RxSWIN（RX軟件識別號）生成已有系統的唯一識別軟件版本，

評估軟件更新與目標車輛的兼容性、更新系統的相互依賴性、通知車輛用戶更新的能力以及車輛所有軟件更新的記錄。

這種方法還包括車輛類型的專用功能。軟件更新的真實可靠性和完整性應通過以上步驟獲得保證。

更新失敗也是需要進行管理的，例如，通過將系統恢復到以前的版本或進入安全狀態。還需要確保OTA軟件更新之前、期間和之后的車輛安全。

在這種情況，ISO/FDIS 24089[11]標準的目標是支持第156號UNECE法規的執行。用于解決執行軟件更新的基礎架構、涉及的車輛和車輛系統、軟件更新包的開發以及軟件更新活動的運行。目前，ISO文件仍處于起草階段，計劃于2023年初發布。

2.10確保軟件環境的安全，防止黑客入侵

隨著車輛功能由軟件定義，從而變得更加通用，相關安全風險預計會不斷變化，并可能增加。這對于定義安全風險的兩個因素來說是正確的：1.成功攻擊的潛在影響（特別是在自動駕駛領域）2.成功攻擊的可能性，因為更高的軟件復雜性與漏洞概率的增加直接相關。當今的安全方法主要集中在車輛開發和設計階段，因此需要延伸以覆蓋SDV生命周期。

此外，需要通過持續的安全監測和風險管理來修改安全方法。這些概念包括以下功能：

利用入侵檢測系統檢測車輛中的潛在入侵，

通過車輛安全運營中心持續監控車隊安全并統籌攻擊遷移

通過各自車輛和云端能力來阻止和/或應對新發現的攻擊

2.11在基于開源的生態系統中合作

過去，汽車行業在構建新技術時通常面臨兩種選擇：“制造與購買”。雖然“制造”選項提供完全控制，但在就開發和運營而言，它是最昂貴的選項。它需要稀少而多樣化的技能，最終可能會成為難以在市場上成功且跨車系或品牌復用率低的一個利基小眾解決方案，另一方面，“購買”選項可能會導致供應商或技術鎖定，從而降低在市場上差異化的可能性。

其他行業已經成功地展示了通過利用開源社區而帶來經過驗證和充分測試的優勢，例如免于技術鎖定、廣大技術人員的力量、可靠性和免費測試、縮短上市時間或提高安全性。

將其適應汽車行業提供了一種更靈活、更平衡的解決方案以擺脫“制造或購買”：開放式SDV計劃推動所需技術在非差異化構造塊上的開發和增強。因此，汽車行業可以分享基于在一個開放技術平臺、標準，和以開源車內協議棧為中心的框架上的成就。利用開放標準和供應商中立的治理模式可以避免市場分裂，并為OEM提供廣泛采適用的技術平臺和解決方案。此外，在這些開放的、經過測試的、無差別的要素上構建軟件可以釋放出寶貴的開發人員資源。Eclipse SDV工作組、COVESA聯盟或SOAFEE項目在這些上是公認先進的典范。

三

結論

軟件是OEM滿足客戶期望的關鍵差異化因素。由于它解鎖開啟了新的使應用用例和收入模式，也成為了延長車輛生命周期的推動者。

對軟件的巨大需求和增長導致OEM面臨多項挑戰，例如處理復雜性，同時保證整個技術鏈的安全性，以便將新軟件引入車輛。本文全面概述了這些挑戰，并概述了OEM為成功克服這些挑戰所需要的技術方案。這些方案涵蓋了汽車價值所在定位、使用哪些開發工具、需要考慮的相關云服務和車輛組件等方面的心態理念轉變。在這個前提下，強調了行業法規和基于開源生態系統的必要性。同時把上述那些不同的構造塊結合在一起，將使OEM及其解決方案提供商能夠簡化、加速和自動化軟件的創建和測試，以改進開發、節省上市時間并降低成本。

審核編輯：劉清