Google Cloud 虛擬車輛延伸至 AAOS 以外，涵蓋最小型控制器

Google Cloud 正將其虛擬車輛開發方法擴展至座艙以外，瞄準那些令軟件團隊必須等待硬件到位的小型控制器。Google 在 10 月 20 日的公告中描述，透過 RemotiveLabs 將 Android Automotive OS（Google 的車載作業系統）與模擬車輛網絡連接。Google Cloud 虛擬車輛旨在讓這些原本分隔的系統更早進入整合測試。

核心矛盾相當實際：單獨測試儀表板，無法證明它會否與汽車其他部分交換正確資訊。軟件定義汽車的功能在很大程度上依賴軟件，仍需各個元件之間協調運作。Google 所針對的，是已可遙距測試的軟件團隊，與工作仍受制於實體設備的團隊之間的落差。

AWS 先前曾介紹互連的虛擬汽車元件，為 Google 的方法提供了一個有用參考。買家需要問的是，這些環境可反映多少實際量產行為，以及究竟能消除哪些開發延誤。這個區別比起示範能否展示一個逼真的虛擬座艙更重要。

Google Cloud 虛擬車輛將整合測試延伸至座艙以外

這項公告將焦點由運行個別車輛應用程式，轉向測試各車輛系統之間的連接。

Google 的 虛擬車輛架構結合 Android 的虛擬測試環境與 RemotiveTopology；後者是一項用於描述及運行互連車輛元件的工具。其宣示的範圍由座艙運算延伸至微控制器單元（MCU），即嵌入控制系統中的小型電腦。

這是一項開發建議，而非宣告車輛硬件已變得不再必要。它亦關乎工程師在哪裏建構及測試軟件。讀者不應將雲端開發理解為行駛中的車輛必須依賴遙距伺服器。

電子控制單元（ECU）是負責特定車輛功能的電腦。關鍵的整合問題在於，當其輸出成為另一個元件的輸入時會發生甚麼事。一個元件即使按開發人員的預期運作，仍可能與另一團隊對共用訊號的理解不一致。

以切換駕駛模式作為例子。座艙可能顯示已選取的模式，但另一個元件仍回報先前的狀態。每個應用程式或許都能通過獨立檢查，但合併後的行為仍會不一致。測試這項互動可讓分歧浮現。

這個例子亦說明，虛擬車輛需要的不只是吸引的畫面。真正有用的產物，是一套可執行的軟件、連接、輸入與預期回應安排。其價值取決於這個安排可回答哪些工程問題。

因此，評估此類環境的產品經理應問：開發流程有何改變？團隊能否在設備到貨前調查介面分歧？另一名工程師能否重現故障？供應商更新軟件後，同一情境能否再次運行？

這些問題把廣泛的基建公告化為可評估的工程主張，同時亦界定了相關說法的邊界。一個能及早捕捉通訊錯誤的環境，即使未能重現量產車的每一項實體特性，仍可帶來價值。

對開發人員而言，眼前機會是可更早接觸相鄰系統。對項目主管而言，則是可更早取得有關整合假設的證據。這些好處需要參與元件具備有用的表徵，而不只是提供更多可用雲端容量。

這亦是 Google 強調小型控制器的重要原因。當開發環境涵蓋阻礙有意義測試的依賴項時，其相關性便會提高。然而，擴大範圍只有在新增元件能代表工程師實際需要檢驗的行為時才有幫助。

供應商面臨更早交付可測試行為的壓力

更早整合改變了汽車製造商向供應商所需的要求，包括相關資訊何時必須可供使用。

按照 Google 所描述的方法，開發里程碑會轉向向共用環境提供可運行的貢獻。該貢獻可能包含量產軟件，亦可能只是預期行為的有限表徵。無論是哪一種，其範圍都必須明確。

對供應商而言，這形成了一項需要協商的額外交付項目。僅提供網絡描述，並不能回答元件如何反應的所有問題。提供可執行軟件則引出關於存取權、維護及該軟件允許用途的獨立問題。

汽車製造商亦須承擔相應責任。必須有人決定哪些元件版本應組合使用、哪些假設仍屬暫定，以及哪些故障會阻礙後續開發。把測試提前並不會自動分配責任歸屬。

此處，進度壓力會變成組織壓力。虛擬環境可在實體整合前揭示分歧，但參與團隊仍需要一套解決流程。無論測試在哪裏運行，未獲解答的介面問題始終未獲解答。

有用的驗收準則應界定供應商貢獻必須支援的行為。例如，團隊可要求元件回報狀態轉換，並處理遭拒絕的請求。這比要求與虛擬車輛普遍相容更具可操作性。

這個區別對小型供應商同樣重要。買家應評估製作及維護有用虛擬貢獻所需的工作量。否則，工作可能被轉移至上游，卻沒有就誰提供資金或保持內容更新達成清晰協議。

現有工程知識亦需要隨可執行環境一同流轉。若決策仍分散在訊息、介面文件及會議記錄之中，測試結果便難以解讀。可重現的故障仍需要說明參與團隊原先有何預期。

一個可搜尋的工程知識庫可協助團隊連同技術文件一併檢索這些決策。它與測試環境的用途不同：前者保留理解及解決結果所需的背景脈絡。

因此，壓力不只落在嵌入式軟件開發人員身上。架構團隊需要一致的定義，採購團隊需要清晰的交付項目，而項目經理則需要與可觀察行為掛鈎的里程碑。虛擬整合策略觸及每一項這些職責。

對企業買家而言，這意味著一種具體的評估方法：選取現有的整合依賴關係，並追蹤每名參與者必須提供甚麼。這項練習會揭示建議平台究竟減少了等待，還是只把缺乏協議的問題更早暴露出來。

兩種結果均可提供資訊。及早看見問題固然有用，但買家在評估供應商的進度聲稱時，應將其與問題已獲解決區分開來。

車輛即程式碼使連接關係成為軟件的一部分

此機制取決於讓系統安排連同在其中運行的軟件一樣可被重現。

車輛即程式碼是指以工具可解讀及執行的檔案，表達車輛的電子架構。架構描述成為工程師可以審閱、版本管理及重用的內容，為參與元件提供共同參考。

RemotiveLabs 的車輛即程式碼概念區分平台描述與可運行實例。平台描述可用的元件及其通訊路徑；實例則選定要執行的特定設定。

這個區別可避免一項重要誤解。描述完整架構並不代表該架構內每個元件都會在每一項測試中運行。聚焦的設定可回答較狹窄的問題，前提是其邊界保持清晰可見。

文件亦區分量產軟件、模仿元件行為的行為模型，以及提供由測試控制回應的模擬物件。這些表徵各有不同用途，其存在應影響工程師如何解讀測試通過的結果。

例如，模擬物件可提供測試顯示器錯誤處理所需的精確回應。該結果可對顯示器說明有用資訊，但對最終量產控制器會否在同等條件下產生該回應，則說明較少。

分析優勢來自追蹤這些區別，而非將它們隱藏。測試環境應能讓人識別實際運行了甚麼。否則，「完整車輛」一詞可能掩蓋架構覆蓋範圍與量產軟件覆蓋範圍之間的差異。

設定一致性是另一項限制。RemotiveLabs 的平台描述可納入現有汽車網絡檔案，包括描述系統或通訊資訊的 ARXML 及 DBC 格式。其文件要求在合併相關檔案時使用相容的名稱、設定及版本。

這項要求值得注意，因為匯入檔案並不會協調相互矛盾的工程決策。若團隊提供不相容的定義，自動化環境仍需作出處理。可重現性讓分歧更容易調查，卻不會決定哪個定義正確。

對 Google Cloud 虛擬車輛而言，實際承諾是軟件與其周邊系統之間可供審閱的關係。軟件變更可根據已知安排進行評估；架構變更同樣可成為審閱中明確的一部分。

持續整合，即自動建置及測試變更的做法，為這種關係提供了情境。有用的證據單位，會成為在已識別設定中測試過的軟件修訂版本。脫離該設定的結果較難令人信賴。

這改變了團隊討論覆蓋率的方式。只計算已連接元件並不足夠。買家需要知道哪些互動已獲測試、哪些實作有參與，以及哪些假設補足了其餘行為。

因此，最有力的示範應顯示一項工程分歧如何變得可重現，然後獲得解決。這比聲稱整輛車能在雲端啟動更能說明問題。

AAOS 虛擬測試仍有硬件邊界

即使是忠實的軟件環境，仍需要清楚說明硬件依賴行為的界線。

Cuttlefish 是 Android 的可配置虛擬裝置，亦是這套架構中既有的一部分。Google 的 virtual Android devices 文件說明可在本機或遠端執行，並強調其對 Android framework 行為的忠實度，同時指出涉及特定硬件實作時仍存在差異。

這項限制與公告直接相關。Android Automotive OS（常簡稱為 AAOS）可以參與更大型的測試安排，但這不代表所有參與的硬件互動都完全等同。擴展環境的涵蓋範圍，並不會消除其中的差異。

硬件抽象層是把作業系統連接至裝置特定功能的軟件。Cuttlefish 的文件明確指出，這個範疇是它與實體裝置存在差異的來源之一。買方在解讀更廣泛的虛擬車輛主張時，應保留這項限制。

同樣的審慎態度亦適用於共用的處理器架構。相近的執行基礎可支持一項開發策略，但買方仍需要取得關於特定目標的證據。任何軟件兼容性說法，都應說明所比較的軟件、硬件假設及行為。

當標題由座艙運算延伸至最小型 MCU 時，這點尤其重要。呈現控制器的訊息，與執行其量產軟件並不相同；執行該軟件，亦不等於重現它與實體周邊環境的每一項互動。

這些差異不會削弱虛擬測試的價值，而是界定測試結果可證明甚麼。只要其假設與工程師嘗試解答的問題相符，範圍明確的結果可以非常有用。

問題在於這個範圍在轉述過程中被擴大。一次成功的介面測試，可能被演變為整個系統完全等同的說法；一次雲端示範，可能被演變為餘下驗證工作已經消失的說法。兩項結論都不會自然成立。

Google 與 RemotiveLabs 表示，在早期客戶合作中，整合週期加快超過 10 倍。該公告未有提供足夠的方法細節，讓人把這個數字視為普遍基準。讀者在套用到自身項目前，需要知道基線、量度的活動及仍須完成的工作。

評估應區分經過的等候時間與工程投入。取消設備排隊等候固然有價值，但其量度的內容不同於縮短缺陷調查時間。把兩者合併為單一的加速數字，可能掩蓋實際效益。

買方亦應問，測試環境改變後，發現是否仍然成立。虛擬環境中識別的問題，會否在預期的實體條件下出現？建議的修正方法能否同時處理兩種環境？這些問題有助評估相關性，毋須要求普遍等同性。

因此，所得判斷會比「硬件已被取代」的說法更狹窄而實際。AAOS 虛擬測試可以支持更早期的整合，同時工程師仍可持續確認哪些結論能跨越硬件界線成立。

AWS 為互連虛擬元件提供先例

Google 的做法加入了一項既有趨勢，目標是讓汽車整合較少依賴實體開發目標。

AWS 於 2024 年 6 月 13 日描述了一套相關架構，採用 Panasonic Automotive vSkipGen 和 ETAS RTA-VRTE StarterKit。其 interconnected virtual targets 連接供應商環境，以支援更早期的整合。已發表的設定亦處理了協作問題，讓參與者毋須公開其原始碼。

這項先例為目前公告提供了背景。透過雲端基礎設施連接汽車軟件元件，是一個既有方向。評估 Google 的貢獻時，應聚焦其具體整合路徑、支援的環境，以及對參與工程團隊的實用性。

這項比較並不能判定誰勝誰負。引用的資料描述不同安排，亦未提供共同基準。任何有關相對完整度或效能的說法，都需要等同的工作負載及清楚對應的評估準則。

對於希望從競爭角度理解 Google 虛擬車輛的讀者，有用的比較在於開發依賴關係。哪一種做法適合專案目前使用的元件？哪些供應商貢獻可以參與？現有測試要能執行，仍須完成哪些工作？

安全邊界亦值得在比較中留意。供應商需要合作，同時控制他人存取其工作的權限。買方應評估擬議安排能否支援所需協作，並保留參與者之間已協定的邊界。

這些問題讓核心張力保持清晰：較早的共享測試，對比等待實體設備才進行整合。雲端供應商競爭只是背景因素。工程決策取決於某個具體安排，是否能為實際專案改變這種依賴關係。

因此，買方不應把雲端品牌視為整合計劃的替代品。可用的運算資源只是整個安排的一部分。元件、權限、測試擁有權及可重現的設定，決定團隊能否有效使用這些資源。

可攜性是另一個合理的評估問題，而非可以直接假定的既有效益。團隊應識別哪些描述、測試及模型可以在其他地方重用，亦應識別哪些依賴項需要替換。

這點相當重要，因為工程投資會延伸至最初示範之後。開發出有用情境的團隊，會希望在元件改變時保留這些情境。在大量測試開始依賴它之前，評估應檢視這條維護路徑。

就 Google Cloud 車輛模擬而言，其競爭機會在於令既有開發工作流程更容易延伸至跨系統邊界。買方需要取得這種契合度的證據。若比較只基於虛擬座艙示範，核心整合問題仍然沒有答案。

AWS 的先例因而強化了這個類別的理據，同時提高差異化的標準。Google 的做法需要展示其特定組合如何改善工程師現時已在進行的工作。

留意涵蓋範圍、量度結果及可重現示例

下一批證據應揭示哪些內容能運行、哪些方面得到改善，以及其他團隊可以重現甚麼。

未來數月，首先值得留意的訊號是更明確的元件涵蓋範圍。有用的披露會區分量產軟件、行為模型及測試控制的替代項目，亦會指出所涉及的作業環境及目標假設。

這些細節可透過令範圍可供評估，強化 Google Cloud 虛擬車輛的理據。欠缺相應實作細節的廣泛架構圖，會令核心不確定性仍未解決。讀者應尋找關於參與元件的證據，而非更宏大的完整性主張。

涵蓋範圍亦必須與實際工程工作連結。新支援的控制器，只有在它解鎖相關互動或移除某項依賴時才具意義。當支援公告包括工程師現時可檢視的情境時，資訊價值會更高。

下一項訊號是界線明確的客戶量度結果。一個有用的個案研究會指出原有工作流程、改變了的活動，以及其後仍然需要完成的工作；它會區分設備等候、測試執行及缺陷調查。

這類報告有助買方判斷所述加速是否適用於自身情況。來自狹窄篩選整合活動的結果，應繼續與該活動連結。重複速度提升的說法而不附帶量度範圍，幾乎不會增加證據。

讀者亦應留意令最初敘事變得複雜的結果。一個環境可能縮短取得資源的延誤，同時增加設定維護工作；它亦可能更早揭示更多缺陷，卻未必立即縮短整個專案。這些結果仍有助說明該方法在哪些地方有效。

最後一項訊號，是由公開示例走向持續評估的更清晰路徑。RemotiveLabs 的 virtual vehicle examples 提供具體起點，包括一個與 Android 相關的示例。該儲存庫把採用 MIT 授權的示例程式碼，與底層 RemotiveLabs 軟件分開。

這項區分對計劃評估的人士十分重要。可公開重用的示例，並不代表每項所需依賴都採用相同授權。買方在假定可不受限制地重用前，應檢視完整的執行環境安排及存取要求。

可重現性會提升公告的實際價值。工程師應能識別示例版本、理解其假設，並辨認它處理哪些量產問題。當另一個團隊能說明其限制時，成功示範會更具說服力。

對工程主管而言，當前行動是從現有專案中選擇一項尚未解決的整合問題。詢問擬議的虛擬環境能否在所需設備到達前解答它。記錄哪些元件包含量產軟件、哪些採用替代項目，以及哪些結論仍需實體確認。

評估範圍應收窄至足以產生可解讀結果。把調查與現行流程比較，當中包括設定及維護投入。把軟件修訂版本、設定、預期行為及觀察結果一併保存。利用這些記錄判斷擴展環境能否移除另一項依賴。當證據支持更早作出工程決策時，Google Cloud 虛擬車輛將最為有用。先從團隊現時無法測試的互動開始，再問一個可信的虛擬結果能證明甚麼。