一摘要

軟件定義汽車（SDV）不再是愿景，轉型已全面啟動，使成熟度成為汽車廠商在競爭激烈的市場中最重要的差異化因素之一。每個制造商都必須經歷三個“階段”才能達到理想的狀態。在第一個階段里，硬件和軟件仍然緊密耦合。2.0階段標志著用例和軟件應用程序呈指數級增長的過渡階段。3.0階段是終局，這時的汽車主要由軟件設置來定義，從而達到完全可編程狀態[1]。這聽起來像是一種自然進化，但也意味著有若干挑戰需要面對。畢竟，我們討論的不是手機，而是一種具有潛在危險性、技術高度復雜且生命周期可能長達數十年的可移動物體。

雖然已經設定了軟件定義汽車的目標，但具體路徑仍不明朗 [2]：汽車廠商各自處于轉型的不同階段，并以其自有“歷史”E/E架構和嵌入硬件中的軟件堆棧為起點。要取得成功，了解從硬件定義汽車過渡到軟件定義汽車的主要趨勢至關重要。具備了這些知識，人們才可以重新考量汽車的制造方法以及傳統方法注定會失敗的原因。

在跨入最后一個階段的過程中，不難發現三個主要趨勢領域的轉變：從分布式到集中式，從手動到工具驅動，從閉源到開源。汽車行業的所有創新方法都具備一個共同特點，即對這三種轉變中的一種或多種具有促進作用。ETAS在移動出行領域擁有數十年的經驗，并與汽車廠商建立了密切的關系。因此，本文所描述的趨勢都是基于第一手資料和信息。如果各個汽車公司想保持競爭力并從這些轉變中受益，而不是被甩在后面，那么了解進入終局時代所需要采取的措施便極為關鍵。

本文研究的是與軟件相關的趨勢。與網絡安全相關的挑戰和原則見“軟件定義汽車的網絡安全”[3]一文中的闡述。

二導論

要從傳統汽車轉為軟件驅動汽車，制造商需要經歷三個階段。首先，軟件和硬件之間的聯系仍然十分牢固。如今行駛于路上的許多汽車都是第一個階段的產物。代碼爆炸標志著向第二個階段的過渡，并且現已成為制造商產品的一個重要組成。軟件和數字服務是除硬件組件之外的兩個顯著特征。我們目前正身處一場競賽之中，軟件定義汽車得到完全發展的第三個階段這一目標已十分明確。然而，應對諸多挑戰的正確方法仍有待探索。從數字上看，代碼（所有新功能的DNA）數量正在不斷增長，并且我們所談論的不只是某個單一的汽車單元；產出車型（包括其變體在內）數量將不斷增加，每種車型的預期壽命為數十年，并且需要持續維護。

對于汽車廠商來說，這意味著要為每種車型處理各種成套的組件（例如，傳感器、控制單元、通信模塊等），每個組件都有各自的規格和配置，由不同的供應商提供。因此，跟蹤設備版本、固件更新并確保與系統總體設置的兼容性將成為一個主要問題。簡而言之：為了滿足客戶的需求和愿望，缺陷修復、維護和更新所需要的代碼數量正在呈指數級增長。如今的汽車代碼數量大約為1億行，而一架客機的代碼數量大約為1500萬行。換句話說：現代乘用車的代碼行數是飛機的6.5倍。這樣比較有助于清晰了解這個數字的大小。隨著軟件定義汽車的出現，行數將進一步增加，到2030年預計將達到3億左右[4]。在此情形下，汽車行業對代碼復雜性管理策略的需求十分迫切。

作為比較，我們可以參考智能手機的轉型過程，即智能手機制造商在經過各個階段后生產出幾乎完全由軟件定義的產品的歷程。雖然用戶對于在整個生命周期中擁有靈活、基于應用程序和個性化體驗的期望極為相近，但這兩種物品的性質卻截然不同。一方面，汽車在很大程度上仍然屬于機械物體的范疇，其設備、組成和依賴性要復雜得多，即使是最輕微的軟件故障也具有潛在的危害。另一方面，它的使用壽命要長得多，使用場景可能也不盡相同。

了解過程的獨特性以及通往軟件定義汽車之路所伴隨的挑戰，這一點十分重要。作為一家經驗豐富的汽車行業硬件和軟件提供商，ETAS不僅洞察全球趨勢，并嘗試預測其進一步的發展趨勢。通過對全球和地區需求的比較，可以發現若干有趣的差異。應該持續觀察轉型過程，以更好地了解全局（圖1）。

圖1：與軟件定義汽車相關的各種預測。

三軟件定義汽車——全球轉型

圖2：2021年全球互聯車隊規模， 2025年、2030年和2035年按地區預測（單位：百萬輛）[11]。

邁向第三個階段的競賽已經啟動，盡管其光芒尚被另一項重大變化——向電動汽車的平行轉型——所遮蔽。在這兩種情況下，傳統的差異化因素（包括品牌忠誠度）都已退居幕后；市場正在重新洗牌。老牌制造商們不能再依賴于良好的聲譽或卓越的機械性能，否則，它們將被創新型后起之秀所取代。

例如，歐洲、北美和日本的制造商正在承受著來自中國的壓力（圖2）。中國汽車只在當地低價銷售并且質量堪憂的時代已經畫上了句號。現在，它們正在與全球市場上的成熟品牌并駕齊驅，尤其是在電動汽車方面，價格下降的同時創新性功能與日俱增。而從世界范圍來看（例如在歐盟和美國），西方汽車廠商卻正在提高此類最先進汽車的價格，因為它們在日益復雜的開發工作上投入了大量資金[12]。

研究中國經濟的專家Frank Sieren對傳統制造商似乎落于人后的原因做出了三點解釋：首先，產品面市時間長，例如德國汽車廠商的產品面市時間約為48個月，中國制造商只需要30個月。其次，中國市場希望軟件定義汽車比傳統汽車便宜，因而迫使地區制造商優化其開發和生產流程。最后，中國買家通常更關注數字化效果而不是外觀[13]。

歐盟要求2035年所有售出汽車實現零排放。因此，可以假設，屆時將極有可能不再銷售搭載內燃機的汽車（又名內燃機汽車，ICEV）。未來的完全軟件定義汽車可能會在某個時點成為電動汽車。此外，電動發動機本身將不再是賣點——快速轉型為軟件定義汽車的重要性因此而再次成為我們關注的話題。

正如我們所看到的，中國制造商已經成為電動汽車領域的主要創新驅動力。但這是否意味著它們在軟件定義汽車開發方面也處于領先地位呢？根據預測[14]，2023年至2032年，亞太軟件定義汽車市場將成為最振奮人心的市場。但是，北美和歐洲仍被視為該時段里重要的軟件定義汽車地區。盡管如此，鑒于中國汽車行業的研發動態和速度令人困惑，其內部存在的一些趨勢仍然值得探討。

在2023年上海車展上，地區制造商們展示了它們的軟件定義汽車愿景，并提供了多種內部軟件定義汽車解決方案，如中央或跨域計算平臺，用以降低汽車開發成本并縮短汽車開發時間。硬件和軟件等方面的用戶體驗也頗受關注，使制造商們能夠將需求旺盛的技術（例如娛樂系統）集成到汽車中[15]。在汽車銷量激增的推動下，預計到2030年，亞太地區將在嵌入式車載信息娛樂系統市場上占據最高份額[16]。

根據預測，歐洲和北美制造商未來幾年將保持其在軟件定義汽車行業的市場主導地位，但之后情況如何尚無法判斷。亞太地區的客戶似乎越來越趨向于從地區汽車制造商手中購買汽車，尤其是電動化、復雜化、互聯化、靈活化和數字化的汽車。此外，中國制造商在其他地區的汽車銷售數量正在攀升，其全球市場份額也因此而緩慢增加。要想不依賴于汽車廠商及其發源地而擴張至更多全球市場，便需要制造商們以自適應的方式創建解決方案（硬件和軟件），從而滿足不同地區的需求。

四進入軟件定義汽車的終局時代——三大趨勢

階段1

硬件與軟件解耦、集中化，以及越來越多的可復用軟件功能

階段2

應用、服務和用例迅猛增長

階段3

完全可編程的軟件定義汽車

圖3：在邁向完全可編程軟件定義汽車終局時代的過程中，三大趨勢占據著主導地位。

核心問題是：目前哪些趨勢正在推動著軟件定義汽車向前發展，并且，最重要的是，在規劃自有變革流程時應該考慮哪些趨勢？這不僅是汽車廠商關注的主要問題，也是供應商、第三方開發商和后續合作公司最關切的議題。畢竟，我們都在同一條船上，在汽車的整個生命周期中，加強合作、共享愿景才是關鍵。

向完全軟件定義汽車的轉變可被劃分為三個主要趨勢領域：從分布式到集中式，從手動到工具驅動，從閉源到開源（圖3）。在我們深入探討之前，先看一下順序。在某種程度上，趨勢領域與邁向軟件定義汽車理想狀態的三個階段大致相符，集中化是更多工具驅動和自動化汽車開發流程的一個先決條件。并且，我們在這條路上走得越遠，整個行業內的合作和協同效應的重要程度就越高。但開源方法的實施需要在該過程的早期階段得以解決，以便在長期范圍內釋放其全部潛力。

因此，趨勢領域具有緊密相連的特性，它們相互依賴并相互促進。要進入第三個階段，三者都需要具有極高的成熟度。

五從分布式到集中式：再定義汽車軟件

在過去幾十年的汽車開發中，軟件功能被緊密集成到特定的電子控制單元（ECU）中，由不同的供應商以軟件—硬件捆綁包的形式提供。對于功能數量可控的汽車來說，這不失為一種很好的解決方案。隨著汽車對于功能的需求不斷增長，需要集成的ECU和子系統的數量激增：一輛典型的乘用車目前有大約150個單獨的ECU，使其成為一個高度復雜的系統[17]。

當涉及到新功能時，客戶期望開發時間更短、速度更快。但由于復雜程度不斷提高，汽車行業當前的現實情況卻與此相背：開發人員將60%以上的時間花在了維護、檢測、文檔化和手續辦理上，而不是花在開發新功能或滿足客戶最新需求方面。每當即將推出的車型需要新的ECU捆綁包時，一切都要重新開始。這種以項目為中心的方法使得所實現的功能代碼很難從一輛車轉移到另一輛車，從而對可復用性形成了制約。

即使車已上路，工作也不算結束，仍然需要頻繁地進行軟件交付和更新（包括安全相關的更新），而這一切在上述條件下幾乎無法完成。根據麥肯錫的說法，過去十年間，軟件復雜程度提高了4.0倍，而開發生產力僅增長了1.0至1.5倍[18]。要開啟完全軟件定義汽車的旅程，首先需要解決的便是這個問題。

此時，硬件與軟件解耦以及集中化的趨勢已經形成。開發人員并不希望將數百個單獨的CPU與其功能特定的代碼和工具進行集成，而是希望采取一種協調一致的方法。減少ECU的數量并將功能和計算能力捆綁到少數分區性ECU和汽車計算機上是一個重要趨勢，也是遍布世界各地的渴望保持競爭力的汽車廠商面臨的主要挑戰之一。

將分布式E/E架構重塑為集中式架構不僅涉及IT知識，還會改變我們的合作方式，尤其是在與供應商和內部/外部開發人員開展合作時。這種全新的協作性、快節奏的工作方式只能以有限的程度映射到原有的既定流程中。同時，在DevOps原則范圍內也存在著轉向迭代開發流程的趨勢。采用這種方法可以使汽車整個生命周期中的工作得到持續優化（圖4）。

文化層面的考量以及E/E架構的重新安排都是SDV的首要步驟，也是其先決條件。然而，它們對客戶本身并沒有什么影響。用戶不會注意到一項功能是集中受控還是分布到了不同的ECU上。因此，這算不上銷售論據。他們能夠注意到的是軟件連續更新速度加快以及新功能固有的可用性。當前的任務便是以最佳方式利用這些新的開發流程和原則，從而創造附加價值。

DevOps環展示了一種全新的迭代式

軟件開發和運維方式

其中以永久性優化為重點

轉向DevOps范式，以便在保持質量的同時提高交付速度

圖4：向DevOps范式的轉變

六從手動到工具驅動：便利性和效率是未來的核心因素

2022年，汽車軟件的價值約占整車價值的20%，2030年預計將達到40%以上[19]。從這些數字來看，很明顯，汽車的數字化程度將成為未來的差異化因素，最終客戶所期望的正是最先進的汽車配置。硬件和軟件的解耦本身并不能顯著加快開發速度從而滿足不斷增長的需求，而需要最大限度地減少手動工作量以縮短軟件創建和測試用時。必須能夠使開發人員專注于實際功能，而不是耗時的任務。

在標準化方面，AUTOSAR Classic作為一種適用于安全性和硬實時ECU的綜合解決方案，已被業界廣泛接受。然而，隨著主要ECU軟件功能向集中式汽車計算機轉移，AUTOSAR Adaptive因其面向服務的架構（包括功能安全性和軟實時功能）而受到若干汽車廠商的青睞。這兩項AUTOSAR標準都以減少分布于汽車內各種（通常與安全性相關的）執行器之間的汽車功能的集成和管理工作量為目的。它們采用的是整個行業普遍認可的標準化格式和接口，因此，開發人員不需要每次都從頭開始安排工作。

盡管如此，它仍是一種以ECU為中心的方法，重點關注的是安全相關域。每位開發人員都應該深入探究E/E體系結構的細節，即使只想開發一種簡單的新功能，例如關于駕駛員舒適性的功能。由此可以觀察到將功能性向非安全域轉移這種新趨勢的出現，即主要利用工具支持的環境（帶有可針對汽車API實施的SDK）進行應用程序開發、測試和發布管理。它允許開發人員完全專注于實際功能和用戶體驗，而無需關心底層架構、安全和保障問題。

在此背景下，用于運行這些功能的各種中間件和框架（即所謂的車載應用）已發布完成。AUTOSAR Adaptive上可以部署安全關鍵型應用，而非安全關鍵型應用有更多選項可用。我們看到基于安卓汽車操作系統（AAOS）的信息娛樂應用非常受歡迎。此外，在輕量級容器框架上運行的容器（靈感來自云原生方法）的使用也具有巨大的吸引力。高級駕駛員輔助系統（ADAS）和自動駕駛（AD）中間件[20]以及通常部署在QNX等安全關鍵操作系統上的應用是一個特例。然而，在進行機器開發和基礎架構測試的情況下，可以在非安全域中進行部署。此外，我們最近發現汽車廠商越來越多地要求將功能性轉移到非安全關鍵域，即質量管理（QM）域，以便提高開發靈活性和開發速度。這一趨勢隨著安全關鍵型Linux[21]等的發布而有所增強，例如，它可以以串聯方式部署ADAS/AD中間件[22]，或者使用受保護的執行器接口[23]來限制和處理對安全域的訪問。在這些促成因素的幫助下，開發人員可以靈活地實施QM域中的安全關鍵功能，同時保持所需的安全級別。卸下了這副擔子之后，開發人員不一定要為該制造商工作，也不一定要明確地為某一特定汽車進行編程。接口的標準化使得將軟件推廣到不同的車型成為可能。這不僅可以縮短開發時間，而且可以以最佳方式利用擴展效果。汽車廠商可以在其整個汽車產品組合中對軟件加以“重復使用”。

通過標準化和特定域編程等方法，我們離實現方便、高效的開發流程的目標越來越近。盡管如此，制造商還是低估了流程的復雜性——從設置開發環境到測試、部署和更新，尚有許多步驟需要手動完成。因此，以工具驅動的方式處理DevOps周期的各個步驟是一種日益明顯的趨勢。這基本上意味著盡可能地實現自動化操作，以便使開發人員能夠通過一個直觀的界面，為以前復雜的編程任務提供一鍵式解決方案。預定義的構建塊、現成的軟件環境、適用于重復性任務的模板、循序漸進式手冊以及適用于現有編程平臺的汽車特定附加組件使工具箱日益擴大，而不僅僅局限于開發流程。

汽車廠商面臨的關鍵挑戰之一是在軟件開發流程即將結束時的軟件快速集成，這時通常會發現一些問題，導致汽車生產延遲啟動。其中一個難點在于設置足夠準確的測試環境來模擬真實的行為（以提供詳細的反饋信息來查明根本原因），并自動、靈活地運行和重復（回歸測試）。在測試和集成方面，采用基于云的工具和環境已經成為大勢所趨。例如，從云端進行虛擬測試的方法越來越受歡迎，它允許以所需要的準確度進行ECU模擬，同時最大限度地減少對于成本高昂的真實測試的需求，并顯著提高交付速度[24]。

加速軟件交付的另一個難點在于通過基于云的空中傳輸（OTA）進行更新，以便將含有新功能的軟件分布于汽車上。根據市場預測，2027年，使用中互聯汽車的數量將從1.92億輛左右大幅增長至3.67億輛[25]。然而，關鍵的挑戰不僅是對如此多的汽車進行更新，而且是在軟件各組件之間的依賴關系不斷變化的情況下，對不同車型及其變體的各類更新（例如，AUTOSAR Adaptive、經典ECU、信息娛樂系統更新、連接單元的自行更新、汽車計算機更新、容器更新等）提供支持。汽車連接完成時需要動態地創建活動，以便在幾小時內而不是幾天內完成所需軟件的分布。能夠單獨執行OTA更新可能很快就會成為一種商品用例，因為許多汽車廠商和軟件供應商都非常重視這一主題。因此，問題根本不在于汽車廠商能否提供OTA更新，而在于其具體的差異化因素能否產生速度更快也更加靈活的效果，例如通過依賴關系的自動化處理、綜合性測試功能和/或其他增值終端客戶功能來實現。

因此，成功的關鍵在于顯著提高從軟件創建（例如，用于各供應商實現的ECU）直至在汽車廠商制造的汽車內實現一系列可用性所需要的速度。

汽車行業正在與許多領域競爭開發人才；青年才俊十分罕見。而軟件和工具驅動的開發會吸引青年專業技術人才加入該行業，因為這種工作方式（快速、迭代、面向功能且具有創新性）符合他們的需求，使他們可以利用其熟悉的最先進的多用途編程語言，而不用學習復雜且過時的汽車相關語言。他們認為，向軟件定義汽車的轉變是該行業的重大轉變機遇。最新的Edge方法也很合他們的口味，因為他們熟悉基于LINUX的非安全性環境以及利用云端和邊緣運算的容器化應用程序。開發團隊有來自其他數字化領先行業的青年專業技術人才加入時，其多樣化程度將大幅提升，能夠引入新的理念，也一定會加快實現軟件定義汽車目標的步伐。

七從閉源到開源：個性化、基于云、協同化

當談到開發工具和集中式平臺時，其來自何處是一個主要議題。業內獲得軟件的傳統方式是內部構建或從第三方供應商處購買（構建或購買）。兩者各有利弊（圖5）。內部開發（構建）使軟件本身具有高度的靈活性和定制性，但資源成本高昂。需要在公司內部長期積累專業知識并加以維護。將整個流程外包時（購買），制造商可以十分靈活地選擇市場上最合適的系統提供商，但也取決于具體的產品和價格策略，因此容易出現供應商套牢的后果。這兩種情況很可能都會導致互操作性有限且難以交換軟件組件的專有解決方案。

此外，在這兩種情況下，制造商仍然處在受限于少數外部專家或內部專家的境地。而使用開源軟件（OSS）則是一種有趣的趨勢，制造商可以從社區的協同作用及其對于創新的推動力中受益。汽車廠商已經在通過開源工作組開展合作，這些工作組將迎接業內的各種挑戰，例如一般標準化、平臺和整個開發工具鏈。他們的工作成果可免費向所有人提供；規模較小的公司以及軟件開發人員可以更容易地參與到該行業中來。其總體思路是，通過提供開放的規范和解決方案，讓越來越多的參與者能夠在汽車的整個生命周期中提供服務，而無需關注其實際上正在編程的汽車。

圖5：構建、購買和OSS的優缺點比較。

開源社區已經成為智能手機和電腦等其他領域的標桿。由于供應商套牢是汽車行業的一大擔憂，因此在最初開展OSS計劃方面的合作時，人們尚有些猶豫不決，但現在情況已經改變。Eclipse平臺上的軟件定義汽車工作組[26]、COVESA聯盟[27]或SOAFEE項目[28]等獲得了整個汽車行業的重點關注也收獲了貢獻者。例如，Eclipse軟件定義汽車項目的成員數量從2022年的11位增加到2023年的44位，同樣，OSS項目數量在一年內從0個增加到了22個。

此外，以更加傳統的方式組成的汽車聯盟AUTOSAR和COVESA正在開展密切協作。2022年10月，這兩個聯盟都宣布有意在幾個軟件定義汽車主題上保持一致的動作。COVESA將專注于汽車數據和云交互，而AUTOSAR將為整個系統架構和車載網絡提供開放接口[29]。

圖6：不同開源社區中多種類型的成員（汽車廠商、供應商、行業巨頭、芯片供應商等）對OSS的貢獻在不斷增長。

一般來說，創造售后收入是汽車廠商的一個重要考慮因素。汽車廠商已經在通過新的數字業務模式和用例對這種升級銷售潛力加以利用。開發流程費用高昂并且引入汽車中的新軟件需要長久更新，由此看來，這種升級銷售的結論也合乎邏輯。新功能尤其重要，因為消費者不愿意為汽車“數字功能性”的保持而付費。他們只是希望軟件能正常工作。很少有人會對與機械零件保養類似的持續性軟件維護表示贊賞或理解。

因此，汽車廠商和其他服務提供商需要推出創新性應用程序和升級功能或創新性功能，以優化用戶體驗。軟件不僅能定義汽車，還能對其行為負責，例如在突遇障礙物或危險情況時。要提供此類功能，還有一項挑戰必須面對，即傳統的軟件或功能部署方式不再適用。出現問題后，軟件定義汽車不再僅僅通過手動讀取到的關于錯誤的消息與其制造商或服務提供商進行通信。現代汽車通過空中傳輸方式進行連接，不僅可以接收更新信息，還可以在其整個生命周期中將有用的遙測與診斷信息發送到云端。此時，服務提供商擁有無限多的選項：通過交互式診斷和遠程診斷獲得汽車健康信息、功能執行、按照個別維護計劃進行預測性維護，或通過道路狀況分析數據選擇完美的路線。客戶可以利用應用程序和功能對其汽車進行全面的個性化設置，從而為汽車廠商和其他供應商創造持續的收入流。汽車的使用壽命越長，可以出售的服務就越多。

鑒于許多IT公司已進軍新的領域，汽車廠商開始與汽車行業以外的IT行業知名企業合作也就不足為奇了。這些公司不僅擁有長期積累的軟件開發經驗，而且是智能手機或電腦市場上的知名品牌，對客戶具有一定的吸引力。近期有許多這樣的合作項目對外公布。為了共同構建汽車操作系統，雷諾集團已將谷歌選定為其軟件定義汽車項目的一個關鍵合作伙伴[30]。寶馬已與Microsoft Azure、AWS和IBM等多家公司開展合作[31]。通用汽車與Red Hat開源操作系統合作也已啟動，主要是在Linux方面[32]。梅賽德斯宣布與谷歌建立戰略合作伙伴關系，以整合新的車載數據和導航功能[33]。曾經緊閉的汽車行業圍墻正在一堵接一堵地倒塌，這必定將對汽車廠商的工作文化產生重大影響。除了開發流程迭代加速和敏捷性提高之外，汽車廠商還需要利用更現代的方式將所有參與者整合到一起。這便是基于云的平臺發揮作用的時候了。

八基于云的平臺作為中央加速器

基于云的平臺可通過各種工具和用戶友好界面為軟件開發提供共同的基礎，這對于所有三個趨勢領域都十分重要。開發人員可以專注于價值創造和域特定的主題，而不是通用的非差異化功能。這些平臺具有加速器的作用，是上述許多趨勢和用例的宿主。它們能夠提供長期的成本效益，并對不斷增加的軟件開發成本加以控制。

軟件的開發和測試從一開始便已得到簡化，變為速度更快的自動化流程，從而使面市時間縮短。工作管道由一系列自動化步驟構成，例如，車隊更新快速鋪開，而無需手動針對每種車型做出活動安排。

云技術也是汽車廠商內部團隊與其供應商合作的良好基礎。人們可以隨時從任何地點進入它的共同工作場地，使合作變得更方便，成本也更低。

與軟件即產品（SaaP）相比，軟件即服務（SaaS）交付模式對于邁向第三階段的汽車廠商益處更大（圖7）。通常情況下，基于SaaS的服務和平臺從一開始就被設計為能夠支持越來越多的客戶（又稱租戶）和汽車。它將云原生計算基金會（CNCF）成熟且久經驗證的服務和方法用于基礎架構、開發、運營和監控，主要針對適用于快速和巨大價值創造的預定義構建塊。這使得公司內有限的開發人員/人才能夠專注于差異化功能，而不是將時間浪費在商品功能的基本編程方面。同時，有了SaaS平臺，汽車廠商便不必再開發自有安全功能以及為了滿足法規要求而進行持續改進。基于SaaS的平臺不僅要在安全方面經受眾多汽車廠商的考驗，其為每個汽車廠商提供更多功能的能力也會經受挑戰。也就是說，單獨的功能請求可被轉化為面向所有平臺用戶的總體益處，從而形成一個整體可靠且功能豐富的系統。SaaS平臺通常會提供若干用例。汽車廠商可以首先關注特定的用例，比如OTA更新，然后通過其他用例來擴展其用例組合，比如汽車健康、汽車數據或功能調用。

在成本方面汽車廠商也獲益良多。SaaS通常伴隨著即付即得的定價模式，從而實現公平且靈活的定價、利用和增長。開發成本由許多需要相同功能的汽車廠商分攤。部署和運營成本由租戶共擔。此外，可以根據平臺上的租戶數和較高的汽車數量向基礎架構供應商討價還價，相較一般的汽車廠商與供應商單獨接觸的情況，價格會有所下降。此外，服務級別合同允許在不使用自有資源的情況下快速解決停機問題和故障。在此種情形下，協作為汽車廠商提供了更大的個性化空間和專注于差異化功能的可能。相比之下，在基于SaaP的模式下，用戶僅能獲得以價格相對較低的訂閱費和支持合同使用該服務的權利，而在所提及的其他幾個方面都必須自行管理/組織。

PANTARIS便是這樣一個基于云的集成平臺，可以提供如上所述的所有必要的服務和工具。它擁有一個與云無關的基礎架構，用于在Azure等知名的云上進行可擴展的服務部署和操作。它還提供在云中和整個生命周期上進行汽車連接、管理和操作的基本服務。它能讓汽車廠商專注于差異化服務和功能的開發。通過PANTARIS Marketplace，汽車廠商可以獲得一整套現成的服務。所有服務都是基于SaaS商業模式，使得汽車廠商能夠快速實現其特定用例。

圖7：SaaS與SaaP的比較。

九完全由軟件定義的汽車：我們將走向何方？

毫無疑問：未來的汽車將由軟件定義，第三個階段也終將到來。本文提出的所有趨勢將加快汽車廠商進入最后階段的速度。但是，什么時候才能出現真正“完全由軟件定義的”汽車呢？迄今為止，應用程序、功能、代碼行或任何其他可衡量的實體方面尚未達到最后的里程碑。此外，無論我們這段旅程走了多遠，汽車仍然是現實中運送人員或貨物的機械體。電機功能或電池容量當然可以通過智能應用程序得到進一步優化，整體內飾也可以通過燈光、座椅設置、溫度和娛樂系統實現個性化設置，但有些物理邊界是無法跨越的，它們是由汽車的物理部件所設置。

然而，我們可以在這些有局限性的條件下展望一下未來的軟件定義汽車：上午，為了工作的目的而使用一個完全自適應的軟件定義汽車，它具備所需要的全部設置，甚至擁有針對該特定時間段的單獨的保險。它與一個車隊云服務相連接，該服務可提供在車流中完美穿行直至到達各個目的地所需要的全部信息，如果有會議安排可切換至自動駕駛模式。下午，另一位家庭成員在休閑模式下使用同一輛車，搭配運動設置和娛樂套件。之后，汽車在車庫里充電的過程中，家里十幾歲的孩子上了一堂數字駕駛課，模擬影像被投射到屏幕上。為此目的，包括方向盤在內的消費者可操作部件都會與實際機械裝置分離。也可以為行動不便者切換到一種為剎車和油門分配隨機按鈕的模式。

汽車制造商的開發時間可最大限度縮短，因為整車功能通過經中央計算平臺與云端相連的即插即用部件而發揮作用。消費者可以通過應用商店挑選和下載其所需要的每一項功能或服務，差異化由此形成。這些功能或服務由全球開發團隊設計完成。該團隊由某個主題領域最優秀的專家組成，他們可能在現實生活中從未見過對方，完全是通過在線平臺開展工作。即使到了這一節點，關于如何提高汽車的軟件定義程度也將有新的愿景出現。因此，邁向第三個階段的“競賽”不是關于誰首先達到非現存的目標，而更像是關于保持較快的速度、靈活性和可擴展性，從而在快速滿足不斷增長的客戶需求和其他外部需求方面具備競爭力。而且這不僅僅關系到特定地區崛起的汽車——由于新的靈活性的形成，在全球范圍內銷售汽車變得更加容易。使汽車適應當地的習俗——無論是法律要求、用戶偏好，還是有關天氣、溫度、路況和使用場景的具體特征——將在很大程度上成為軟件更新問題。當某款車型配備了一套最出色的應用程序和功能時，它可以變成“通用型”，在任何情況下都能運行。不過，我們不應將軟件定義汽車視為一件非常復雜的商業化產品。它的靈活性使制造商能夠以極快的速度應對突發或意外事件。這些事件有可能是氣候保護新規出臺、汽車共享運動興起等社會趨勢，也可能是全球流行病等災難，或者政治沖突導致的資源短缺。汽車改裝的可能性變得無窮無盡，并有助于克服當今和未來的挑戰。

總結

軟件定義的汽車面臨著諸多挑戰。即使每個汽車廠商和供應商的關注點和策略可能不盡相同，我們也會對模式和趨勢進行觀察，以應對我們在本文中強調的挑戰。

我們著重指出，在這條道路上，這些地區的開發速度及其向其他地區的擴張速度極為不同，而這可能會改變汽車廠商和供應商的格局。在此背景下，我們介紹了不同地區的不同關注點、需求、速度、增長情況和數量。我們所闡述的核心問題是：“目前哪些趨勢正在推動著軟件定義汽車的演變，最重要的是，在規劃自有變革過程時應該考慮哪些趨勢？”為此，我們將各種趨勢劃分為需要由汽車廠商及其供應商應對的三個趨勢領域：

從分布式到集中式：再定義汽車軟件

我們觀察到了一種硬件與軟件解耦以及汽車計算機中功能集中化的趨勢。功能轉移和集中化將導致ECU減少。集中化還將改變各方開發人員的協作方式，以便為通用的汽車計算機平臺提供功能。同時，協作方式將得到通過DevOps提供的增強型開發流程和范式的支持。

從手動到工具驅動：便利性和效率是未來的核心因素

汽車廠商成功的關鍵是在對軟件不斷增長的復雜性加以管理的同時，顯著提高其開發與部署速度。在這方面，我們看到，隨著主要ECU軟件功能向集中式汽車計算機轉移的需求的出現，中間件和框架的標準化程度與普及性也在大幅提升。在與框架相關的方面，我們發現，人們對車載應用極為關注。此外，將功能轉移到非安全性關鍵QM域的需求越來越大，這也吸引了人們的注意。通過DevOps進行工具增強是提高關鍵開發環節（包括自動化、測試、部署和交付）速度的一種日益增長的趨勢。虛擬測試環境可對此提供支持，使開發人員能夠進一步加快開發速度，同時也便于其集中精力。另一個突出的趨勢是通過基于云的空中傳輸（OTA）進行更新，以便使包含新功能在內的軟件分布于汽車的所有域中。

從閉源到開源：個性化、基于云、協同化

整個行業內部的協作和協同效應有所增強。我們發現不同OSS社區中的成員和項目數量增長強勁，并以移動出行為重點。通過OTA更新能夠引入新的軟件功能（如車載應用），這一合乎邏輯的結論將為汽車廠商和供應商創建新的數字商業模式。因此，我們看到整個軟件價值鏈上出現了許多新的合作伙伴關系。特別是，云計算平臺的興起對上述許多趨勢、用例以及新的合作和商業模式起到了推波助瀾的作用。

在ETAS，我們每天都會與世界各地不同的汽車廠商和供應商打交道，無論是以直接方式還是通過不同的標準化機構、法規和OSS計劃，或是全球政府層面的咨詢。因此，我們可以盡早將這些想法轉化為產品，以便為供應商、汽車廠商和最終客戶提供幫助。

作者

Ismet Akta?博士

ismet.aktas2@etas.com

Ismet Akta?博士自2023年1月起成為ETAS車云服務解決方案領域投資組合管理和入職培訓團隊的一員。他之前曾在與微軟合作的“軟件定義汽車”項目中擔任博世方面（OPS-基于云的后端）的工作流主管。此外，他還曾負責博世各種主題的技術工作，涉及不同領域（如汽車、工業、零售）的技術售前、博世不同部門的技術接口和產品/項目管理等方面。他獲得了亞琛工業大學的博士學位和文憑，專注于通信和分布式系統的軟件架構和跨層優化領域的工作。

審核編輯：湯梓紅