Arm：讓 SDV 成為現實

概覽

SANJAY：我們從拉斯維加斯 2024 年 CES 展場為您帶來另一集《Driving Innovation 》播客的特別節目。在本集節目中，我們邀請到 Arm 汽車業務市場推廣總監 Robert Day。Robert 將詳細介紹 Arm 在汽車領域的布局，以及他們透過 SOAFEE 計畫推動雲原生軟體開發的相關舉措。希望您會喜歡這集節目。

議程

羅伯特：謝謝。首先，我要感謝Sonatus 邀請我們來到他們在 2024 年 CES 展會上的精彩展位，並稍作分享 Arm 如何將「軟體定義車輛」化為現實。關於「軟體定義車輛」的討論甚多，許多人一直在探索各種方法，試圖真正實現這一願景。而這正是我們今天要探討的主題。 根據議程，我們將先簡要介紹 Arm 是什麼樣的企業，以及 Arm 在汽車產業中的定位；接著將深入探討何謂「軟體定義車輛」、為何需要軟體定義車輛，並分享我們的一些計畫——我們相信這些計畫將推動軟體定義車輛成為現實。 首先簡要介紹 Arm 是誰。我們是一家科技公司，主要開發用於矽晶片產品的智慧財產權（IP）。在過去 30 年的發展歷程中，我們取得了相當顯著的成就。如各位所見，目前已有大量基於 Arm 的晶片出貨。我們估計，全球 70% 的人口都在使用內含 Arm 技術的產品。 有趣的是，我曾試著數一數家中擁有多少款 Arm 產品，但後來就停手了，因為實在有點難數。我們觀察到，隨著 Arm 從消費電子展（CES）上的消費性裝置，逐步拓展至汽車領域，這股趨勢正加速發展。而這正是我們今天要深入探討的主題。

Arm 在汽車產業中的應用

羅伯特：所以 Arm 其實在汽車領域已經深耕 25 年了。好吧。 我們幾乎從成立以來就一直深耕車載系統領域。但我們通常都處於「引擎蓋之下」——如果這樣說能讓人理解的話。所以，你看，從這裡的一些數據可以看出，超過 85% 的車載資訊娛樂（IVI）系統都運行在 Arm 平台上，這其實是理所當然的，因為 IVI 系統就像是消費性裝置，只是剛好安裝在你的車上罷了。 此外，隨著新的先進駕駛輔助系統（ADAS）功能與自動駕駛技術的導入，許多應用處理流程也建基於 Arm 技術之上。我們在 Arm 所做的是開發專為汽車領域設計的產品。因此，我們擁有 CPU、GPU 以及 ISP（影像訊號處理器）——稍後我會向各位展示——這些產品的核心特點正是功能安全。我們還擁有一個卓越的汽車生態系統，Sonatus 便是我們的生態系統合作夥伴之一。

為何要採用軟體定義車輛

羅伯特：那麼，為什麼「軟體定義車輛」如此重要呢？首先，從原廠製造商（OEM）的角度來看，這使他們能夠探索新的商業模式、新的營收模式，以及與客戶之間的新型關係。關於軟體定義車輛，顧名思義，早期軟體開發至關重要。由於車輛中將搭載大量軟體，這絕非一蹴可幾。明白嗎？ 但我們看到，軟體定義車輛已成為汽車產業生存的關鍵。有趣的是，這場變革其實早已展開。這是去年高德納（Gartner）的一項預測，基本上指出，到了2023年，前十大汽車製造商中有50%將透過軟體更新提供新功能。 這正是「軟體定義車輛」的核心意義：您可以將這些功能以軟體形式導入，並能進行更新、升級，甚至新增功能。這正是其中關鍵的一環。

我們準備好迎接 SDV 了嗎？

羅伯特：接下來的問題是，身為消費者，我們是否已準備好迎接「軟體定義車輛」？我們是否願意為此付費？Aurora Labs 和 Strategy Analytics 曾在 2022 年（我記得是那一年）進行了一項研究，詢問消費者是否願意為軟體定義的功能與服務付費。如您所見，近 50% 的受訪者表示，他們願意每月支付 20 美元，以換取車輛中的額外服務。 這筆金額換算下來，一年下來相當可觀。更何況是整輛車的使用壽命期間。有些人甚至願意支付高達50美元，這實在令人難以置信。我甚至懶得計算這換算下來一年是多少。

針對 SDV 的新要求

羅伯特：關於軟體定義車輛，關鍵在於它對傳統汽車產業提出了新的要求。因此，我們必須能夠將軟體定義的功能作為先進功能來提供。我們需要推動創新，同時也必須具備敏捷性。因此，這更接近傳統的軟體領域，而非單純的汽車領域。這些功能必須能夠更新，也必須能夠升級；它們必須具備安全性，同時也必須確保行車安全。 最後，它們還必須具備可擴展性。軟體定義車輛的一大關鍵優勢在於，您可以將這些功能和特性擴展應用於不同車型。因此，隨著我們邁入軟體定義的時代，觀察這種動態發展將如何成形，將會非常引人入勝。

Arm 的汽車產品

ROBERT：在 Arm，我提到我們有這些汽車相關產品，因此我們有一系列被稱為 AE（Automotive Enhanced，汽車增強型）的產品。其中有一款名為 Cortex-A78AE 的高效能 CPU 產品。它具備一項名為「分區鎖定」（split-lock）的獨特功能，實際上可讓您將成對的核心鎖定在一起，以達到更高的安全等級。但若您需要高水準的效能，也可以解鎖它們。 這樣一來，基本上就等同於雙核心配置。這項功能主要應用於我們的 AE 系列 CPU 中。此外，我們還有一款功能安全級的 GPU——Mali-G78AE，它具備一套獨特的分區機制，能確保渲染過程的安全性。 此外，我們還有一款名為 Mali-C78AE 的影像訊號處理器（ISP）。因此，所有這些產品對於運行軟體定義功能，以及在車載環境中執行圖形應用程式（這將是軟體定義功能的一部分）都至關重要。而透過 ISP，能夠為車輛提供高保真的攝影機影像，以支援所有先進駕駛輔助系統（ADAS）功能及其他相關應用。那麼，讓我們繼續探討軟體定義車輛（SDV）。

SDV 的四大支柱

羅伯特：在與業界交流的過程中，我們逐漸意識到，要實現軟體定義車輛（SDV）並將其推向市場，大致上有四大支柱。其中最關鍵的兩大支柱，顯然是安全與資安，同時還需要具備即時處理能力。這些本就是汽車產業不可或缺的要素，而軟體定義車輛同樣需要這些基礎。 我們需要一些超越傳統汽車標準的規範。針對軟體定義功能，必須有 API 和標準，讓我們能以此為基礎建構這些功能。我們還需要一些新的軟體方法論。 今天我將進一步探討這一點，因為這是一種很有趣的方式，讓我們能將其他產業的軟體方法論實際引入汽車領域。嗯，非常關鍵的一點——我稍後會再談到——是必須具備在車輛及車載運算系統尚未就緒時，仍能執行軟體的能力。 必須能夠及早著手，並進行模擬等相關工作。而最重要的，我將在最後談到，就是產業內的合作。我們不能再有這種各自為政的狀況了。大家需要攜手合作。這個問題太過龐大，單靠一家公司無法獨力解決。那麼，讓我們來稍微探討其中的一些內容。我們剛才談到的關鍵之一，就是新的軟體方法論。

現代開發流程

羅伯特：因此，我們現在在汽車產業中需要做的是引入現代化的開發流程，以大幅縮短軟體的開發時間與部署時間。我們還需要具備所謂的「環境一致性」能力——也就是當您在雲端進行開發，並將軟體部署到邊緣設備時，若這兩種環境能共用相同的指令集，讓您既能在雲端執行軟體，也能在車載系統中執行，這將是非常理想的。 關於這點，我們稍後會再多談一些。能夠輕鬆地在不同晶片供應商之間進行部署，同樣至關重要。這能讓您的軟體具備可移植性，無論是從一代車型過渡到下一代，還是從某款車型轉換到另一款車型。而這實際上也促成了「左移策略」的實現。我將在下一張投影片中詳細說明。

汽車產業中的「左移」策略

ROBERT：因此，這裡的傳統汽車開發流程相當具有序列化特徵。基本上，你先設計軟體和系統單晶片（SoC），接著開發電子控制單元（ECU），最後才進行應用程式開發。這是一種序列化的流程。 在這些基礎尚未就緒之前，其實很難著手進行太多應用程式開發。而我們採用雲原生模式時，便引入了雲端。若能及早開始在雲端（也就是這裡）進行應用程式開發，那麼在這些基礎工作進行的同時，你便能在此處同步展開開發。因此，我們在此處實現了並行開發。 待系統整合完成後，便可將系統部署至車輛中進行測試。我們實際上是在這裡先進行測試與開發；當車輛或車載運算系統準備就緒時，再將系統部署至車輛中。這還帶來另一項好處——也就是所謂的「左移」（shift-left）策略，從時間軸來看。它同時支援持續的更新與升級，這是軟體定義車輛（software-defined vehicle）的重要因素。 因此，您能夠持續為車輛使用者提供新服務或更新後的服務。這在原廠製造商（OEM）與駕駛者之間，可能形成一種相當有趣的關係動態變化，因為目前若您購買一輛車，通常只是開著它駛離展場，與製造該車的公司其實並無太多互動。反之，若原廠提供更新與服務，您便會與之建立連結。 因此，駕駛者與製造商之間的關係開始產生變化。那麼，我們該如何實現這一點呢？

SOAFEE 倡議

ROBERT：所以，幾年前，我們啟動了一項名為 SOAFEE 的計畫。這是一項產業倡議，其核心目標是為汽車領域的「軟體定義車輛」帶來雲原生軟體開發體驗。明白嗎？為了實現這個目標，我們成立了 SOAFEE 特別興趣小組。我們首先想做的是嘗試定義一套能夠實現此目標的軟體架構。 因此，SOAFEE 首要的任務是定義架構，而非任何程式碼。然而，為了讓大家真正能開始運用 SOAFEE，我們知道必須提供一個參考軟體實作，讓大家能夠著手開發並嘗試這些針對汽車工作負載的新方法論。您可以看到，SOAFEE 的創始成員和管理成員確實橫跨整個汽車生態系統。 其中包括原始設備製造商（OEM）、一級供應商（Tier 1）、雲端技術人員、我們這邊的團隊，以及一些軟體專家。例如 Red Hat 和 SUSE，他們對軟體開發及其整合方式有著深厚的專業知識。因此，我們相信光是從管理機構的組成來看，我們就對目標方向有了相當清晰的認知。稍後我會再向各位詳細介紹 SOAFEE 的成員。

雲原生架構

羅伯特：但我已經跟你們說過，我們其實正在嘗試定義一套架構。如各位所見，我們有這樣一套架構，其中包含一些雲端元件和一些車載元件。不過，重點在於實際的應用程式，而其中許多部分在雲端與邊緣之間將保持恆定或一致。 這意味著當您在雲端開發應用程式或服務時，一旦準備將它們部署到邊緣，這些系統應該就能直接運作。而這正是我們運用容器等技術，以及調度（orchestration）等機制的地方。這些技術某種程度上是借鑒自雲端領域的運作模式，因此已經相當成熟。 人們對這些技術已經很熟悉。我們需要做的，是讓它們適合汽車產業的應用。這實際上意味著，我們必須考量功能安全、即時性、異構運算等要素——這些在雲端環境中未必存在。因此，這正是 SOAFEE 將要應對的挑戰之一。

SOAFEE 會員資格

羅伯特：所以，在過去這幾年裡，我們的會員陣容其實相當不錯。你可以再次看到管理委員會的成員。 我們的會員人數目前已達到——我想實際上應該更接近 115 名。你們可以看這裡，雖然可能看不清楚，但那是「Sonatus 」的標誌。Sonatus 是 SOAFEE 的會員。這完全合情合理，因為Sonatus 目前關注的重點，很大程度上正是「軟體定義車輛」。這屬於「雲端到車輛」的領域。因此，他們是這個領域中極具專業知識的夥伴，我們可以與之合作。

SOAFEE 工作小組

羅伯特：那麼，先稍微談談 SOAFEE 的組織架構。再次強調，我不確定這是否能說明得夠清楚。我們設有一個由 AWS 的比爾擔任主席的治理機構。此外，我們還有一個技術指導委員會和一個行銷指導委員會。技術指導委員會主要負責統籌所有負責實際執行工作的各工作小組，而他們關注的領域包括系統架構。我們正在研究雲原生技術。 我們也在研究混合關鍵性（mixed-criticality），並關注我們認為至關重要的技術，例如虛擬化管理程式（hypervisor）技術。這些成果最終會匯入我們發布的參考實作中，透過開源方式讓大家能盡早使用 SOAFEE。至於我們其他正在進行的工作，其實若回頭看看，你們會發現這裡還有另一個「老虎小組」，那就是「藍圖老虎小組」（Blueprints Tiger Team）。

SOAFEE 藍圖

羅伯特：所以，單純發布一個開源的參考實作雖然不錯，但這在某種程度上還是得仰賴人們主動說：「好，現在我們得做點什麼了。」對吧？ 因此，我們決定推出這些 SOAFEE 藍圖——這是一種參考應用程式，主要針對汽車應用場景，並能在 SOAFEE 環境中運行。它可以是開源的，也可以是閉源的。我們的目標是將範例應用程式引入 SOAFEE 生態系，供大家使用，同時也讓原廠製造商（OEM）能透過現成的範例快速上手。 接下來我將稍微詳細說明這些藍圖的實際運作方式。所謂的 SOAFEE 藍圖，本質上是將部分參考實作運行於韌體和硬體上的時間節省下來。此外，我們還有這些容器。正如我先前所述，SOAFEE 架構的重點之一，正是著眼於工作負載的容器化，也就是一種微服務架構。因此，我們讓不同的工作負載在不同的容器中運行。 各位可以看到這裡的各種軟體元件：我們有應用程式專用的工作負載，還有基礎堆疊，其中包含容器、調度系統、可能的虛擬化平台、工具及其他所有元件。最底層則是運算平台。這就是一個通用藍圖的樣貌。現在我將為各位舉個例子。

Open AD Kit

ROBERT：所以第一個例子是名為「OpenAD Kit」的專案。這項專案是與一家名為 Autoware 的開源自動駕駛軟體公司合作。在這個專案中，我們基本上是將 Autoware 的自動駕駛軟體堆疊拆解成不同的容器，然後讓這些容器透過虛擬網路進行通訊。因此，您可以看到每個容器中分別承載不同的功能：地圖建構、感測、路徑規劃以及車輛介面。 為了確保系統能順利運作，我們在起步階段稍微「耍了點小聰明」。實際上，我們在一個容器中運行了四個完整的 Autoware 副本，但其中僅讓地圖建模功能運作。 為了邁向更完善的微服務架構，我們採取了以下做法：基本上將每項功能獨立置於各自的容器中，因此這裡不再運行完整的自動駕駛堆疊，而是分別運行各項功能。這正是我們目前透過 OpenAD Kit 藍圖所進行的工作。 藍圖的妙處在於——這也是我們開發它們的原因——我們希望業界能採用這些藍圖，並將其作為範例：無論您是原廠製造商（OEM），還是其他科技公司，都能藉此展示自身技術的應用潛力，讓整個系統變得更加精彩。因此，去年有一家名為 Kern Concept 的公司表示：「好，我要回頭研究這些容器化方案。」 我知道其中一項功能——車輛介面——屬於安全功能。如果這功能無法運作，車輛就無法運作。 明白嗎？所以這應該要在安全系統中運行。他們所做的——如果我切換到這裡——是架設了兩個系統。這個系統（指此處）負責運行大部分的 Autoware 功能，而那個系統（指彼處）則負責安全功能，基本上是運行車輛介面，並在兩者之間透過實體乙太網路連接，而非虛擬乙太網路。 這與容器化微服務的概念相同，但現在我們是在異質網路——也就是異質系統中實現。如您所見，安全部分位於此處，可以部署在安全微處理器上（此處為 NXP）；而另一邊則是應用程式流程，這些流程未必需要具備同等的安全等級。

SOAFEE 目標平台

羅伯特：說到平台，我們還需要做的一件事是建立一些硬體平台——雖然地圖上看不出來，但我們的許多晶片合作夥伴都是 SOAFEE 的成員。而我們目前真正努力的方向，就是讓他們將各自的平台帶進來。 讓 SOAFEE（SOAFEE 參考實作）能在這些平台上運行。因此，您可以看到我們有瑞薩（Renesas）、恩智浦（NXP）和馬維爾（Marvell）等公司。我們還擁有來自 AWS 的原生雲端實例。這意味著您可以在雲端上，於基於 Arm 架構的 Graviton 處理器上，以裸機模式運行 SOAFEE。此外，我們也希望納入一些有趣的非汽車級開發平台。 因此我們有 Turing Pi 和 Raspberry Pi。事實上，在昨晚的 COVESA 活動中，Raspberry Pi 正是運行 SOAFEE 的系統之一。好，以上就是關於 SOAFEE 的介紹。

如何參與

ROBERT：如果你有興趣並希望參與其中，SOAFEE.io 會提供你相當多的資訊。 我們有個 Slack 頻道，SOAFEE 也在 LinkedIn 上。如果你想加入，最好的方式就是直接聯絡我：Robert.Day@arm.com。屆時我會協助你成為會員。這就是 SOAFEE。我們相信，這是在將軟體定義車輛變為現實的過程中，極具意義的一環。 若各位有留意，會發現市面上還有其他聯盟，同樣致力於將軟體定義車輛化為現實。但我們各自都處於某種程度上的「獨立世界」，各自負責其中的一小部分。因此，這些部分如何整合在一起，往往並不顯而易見。那麼，這些元素究竟該如何匯聚呢？因此，去年三月我們決定嘗試在這方面提供協助。

SDV 聯盟

羅伯特：因此，我們成立了一個新的聯盟。這個聯盟於昨日正式啟動。這是一項合作計畫——我會稱之為「初步合作」——由四個組織共同推動，這些組織都致力於將 SDV 化為現實。其中包括 Autosar，這可能是其中歷史最悠久的……不，應該說是成熟度最高的聯盟。 還有 COVESA，它以前是 GENIVI 或 GEN IVI。此外還有 Eclipse SDV，以及 SOAFEE。因此，我們正在推動這些不同聯盟之間的合作。這就像是「聯盟中的聯盟」，或者說，如果你願意這麼稱呼的話，就是「合作中的合作」。 僅就這四個組織而言，已有超過 500 家汽車生態系統企業參與其中。這不僅如此，而我們作為聯盟將要做的事情，就是釐清這些組織之間如何相互銜接。事實上，在昨晚的啟動活動中，我們展示了一個示範，讓這些組織的部分系統協同運作，以此展示並說明這確實可行。 這項聯盟真正帶來的，是將雲端到邊緣、聯網汽車、開源技術、開放標準、即時處理與安全等要素，全都整合成一個整體。目標是，若我們能確實做好這一點，應能大幅簡化車廠（OEM）開發與部署軟體定義車輛的流程。同時，這也將鼓勵更多、更深入的合作。 這並非那種各自為政的聯盟式合作，而是真正攜手共進。過去九個月來，我們致力於籌建這個聯盟並推動合作，這段歷程實在非常有趣。如今聯盟正式啟動，工作才剛開始。因此我想說的是，請大家密切關注聯盟未來推出的各項成果。再次提醒，若您有意參與聯盟，可聯繫其中任何一家組織。 最後我想強調的是，這是一個開放的聯盟。我們預期會有其他聯盟加入其中，而不僅僅是我們這四家。因此，我們雖然率先啟動了這項計畫，但也鼓勵其他聯盟參與這個聯盟，並投入這項聯合產業行動。我們深信——而且昨晚我與兩家原始設備製造商（OEM）交談時也聽到了——這正是他們所重視的。 因此，我們希望這將成為一個非常好的開端，真正開啟軟體定義車輛的旅程。我之前提到這項計畫已經展開，但真正需要我們著手的是將其大規模落實。我們希望所有聯盟成員都能齊心協力，共同將此願景化為現實。讓我們跳過這張投影片。

結論

羅伯特：那麼，藉此機會，我想向大家道聲感謝。再次感謝Sonatus 給予我們這個機會，讓我們能前來分享這些關於軟體定義車輛的酷炫技術。也希望各位能享受這場線上直播。非常感謝。