雲端在當今車輛中的角色（第二部分）

概覽

約翰：今天在《The Garage 》節目中，我們將帶來關於汽車雲端運算的特別兩集系列節目第二集，本集特別邀請來自 AWS 的史蒂法諾·馬爾扎尼（Stefano Marzani）擔任嘉賓。在第一集的訪談中，我們探討了雲端運算在數據與運算方面的內容。在本集節目中，我們將延續討論，探討原型開發、數據分析與「AI 」，以及雲端運算在先進駕駛輔助系統（ADAS）與自動駕駛應用中的應用。現在，讓我們繼續與來自 AWS 的史蒂法諾·馬爾扎尼進行對談。開始吧！

主題 3：雲端原型設計與「環境等效性」

約翰：這其實是個完美的過渡，帶我們進入第三個主題——原型開發。正如我之前提到的，我們最近與羅伯特·戴（Robert Day）進行了交談，Arm 觀察到 Arm 架構正被廣泛應用於汽車中的各類子系統。你知道的，我為自己在 Arm 工作了 14 年而感到自豪，所以這對我來說意義非凡。而羅伯特也對此談了很多。 但我認為這也意味著——而且我認為這正是你所強調的重點之一——Graviton 部署在雲端，無論是雲端中的 Arm 架構執行實例，還是車載中的 Arm 架構執行實例，都為原型開發釋放了許多極具潛力的可能性。

斯特法諾：絕對沒錯，是的。 我們稱之為「環境等效性」，對吧？我們是在 2021 年的 Arm 開發者峰會（Arm Dev Summit Conference）上首次提出這個術語的。當時我們在一個工作坊中進行了簡報，該簡報在業界產生了相當重要的影響力與能見度。因為那是我們首次提出這個概念：既然汽車中運行的是 Arm 架構，為什麼我們不能在雲端使用 Arm 架構來運行相同的軟體呢？ 是相同的 Arm 架構，但並非相同的處理器——我們既不知道，也沒有打算將 Graviton 放入汽車中，對吧？汽車的電子控制單元（ECU）其實來自高通、NVIDIA、恩智浦等多家供應商，而這些都基於 Arm 核心。再說一次，這些 Arm 核心，與我們 Graviton 中的核心完全相同，對吧？ 就 Arm 64 而言，當然，這並非完全相同的 CPU，因為我們的 Graviton 基於 Neoverse 架構，而汽車中通常採用 Cortex 架構，但指令集的大部分內容是相同的。

在雲端與車載環境中於 ARM 平台上運行

STEFANO：這就是我們能夠實現的原因，而在構思出這個點子後，我們便付諸實行。因此，現在我們擁有種類極其豐富的嵌入式作業系統——這些系統過去通常只在模擬環境或實體硬體上運作，對吧？——如今卻能在 AWS 雲端上的 Graviton 晶片上原生運行。 例如 QNX、VxWorks、Yocto Linux 和 AGL 等系統。對嵌入式開發人員而言，這是一種嶄新的開發方式，我們收到了令人難以置信的反響——甚至可以說是出乎意料的反應——他們會驚呼：「等等，這只是在雲端啟動這個程序，而眼前竟然出現了 QNX 提示符，簡直就像在使用 ECU 一樣。」 沒錯，這正是我們所說的「環境一致性」。您可以在那裡開始工作。雖然您還是需要硬體，但並非為了啟動開發流程。

在雲端展開軟體開發

斯特法諾：這目前是該產業的一大瓶頸，從原型開發的角度來看也很重要，對吧？如果開發人員——尤其是資深開發人員——總是需要硬體才能工作，那麼就只能採用低階創新，對吧？因為現有的硬體無法滿足需求。

約翰：當然。 從測試的角度來看，就是回歸測試。我們在之前的集數中曾提到，我們也開始採用雲端方式進行自身的測試。因此，與其擁有整排又整排的系統，然後遠端進行電源重啟，不如使用虛擬實例和 EC2。所以我們也在這麼做。我們看到了這方面的優勢，並且正在積極運用這項技術。

汽車產業驗證的難處

斯特法諾：沒錯。沒錯，絕對是。這，這對開發者來說，以及在驗證階段，確實是個巨大的優勢，對吧？ 試著想想看。即便在今天，汽車在某種意義上仍是一個尚未經過深度測試的系統。這是基於歷史原因。正如我們在本集開頭所提到的，汽車正經歷一場深刻的轉型——從現代燃油引擎車輛中由 150 多個 ECU 組成的系統，轉變為數量大幅減少、大約 30 到 40 個、且配備整合式電腦的系統。 雖然仍會有基於微控制器的周邊單元負責感測或驅動，但主要運算將由整合式架構來處理，這些架構內含多組 Arm 核心——可能是 8、12、16 甚至 40 個——形成極度整合的架構。這點至關重要，對吧？這是一項極其重要的趨勢。

透過雲端賦能開發者

斯特法諾：而且你不能指望開發人員把這些設備放在辦公桌上來工作，你必須為他們提供一個環境——一個基於雲原生的環境，原因正如我們先前所見。因為那裡有我們所需的数据、運算選項，還有 Graviton 處理器。因此，這才是開發人員自然會前往的環境，他們可以在這裡尋找工具、進行開發、在硬體上部署，並持續在硬體上進行測試，但反之則不然。

未來五年內，車載軟體的數量將增加三倍

斯特法諾：因為如果從硬體著手，根本就是扼殺創新。你知道嗎？根據某些分析師的預測，在軟體定義車輛（SDV）領域，未來五年內的程式碼量預計將從 1 億增加到 3 億，增幅達三倍。如果還要求開發人員必須依賴硬體來進行開發並產出汽車程式碼，那要怎麼達到這個目標呢？

約翰：哇，這數字真是令人難以置信，我之前還沒有聽過這項統計數據：未來三年內會增加三倍嗎？

斯特法諾：五年。

約翰：這太不可思議了。你知道嗎，我一直在想，我覺得這其中也存在一種良性循環，因為我們在之前的集數中曾討論過工作負載的整合，而你剛才也提到了這一點。此外，我們也談過虛擬化的重要性，以及能夠讓這些應用程式並行運作卻互不干擾的能力。 在我看來，這與雲端原型設計的方法以及虛擬化之間具有相當的協同效應，因為你可以將先前在那裡測試過的相同工作負載，現在讓它們並行共存。而且這與你所說的「環境一致性」——也就是你常提到的那種方法——非常相似。

斯特法諾：是的，絕對沒錯。絕對沒錯。而且再說一次，如果你仔細想想，當你開始擁有 12 個、16 個核心時，你不會把所有核心都用在單一作業系統上，這意味著你需要將這些核心進行分割，並運行多個作業系統。 但這正是我們在雲端所做的事：我們有一個虛擬化程式，能在 Graviton 處理器的 64 個核心上管理多個作業系統，對吧？這完全是一樣的。當然，在電子認證以及許多其他方面確實有所不同。但從軟體工程的角度來看，我們可以採用某種方式，讓這兩種環境非常接近。

約翰：所以這幾乎是在原型開發和測試階段，驗證它在最終實作中將會以何種形式存在，這非常有趣。這……這是我覺得非常著迷的一件事，從技術層面來說非常著迷，而且我認為它作為開發工具也極具威力。

透過「左移」來加速設計週期

約翰：而且，你知道的，我們觀察到——這也是我們多年前就討論過的——關於「左移」的概念：如何運用虛擬原型設計、如何運用雲端技術等，來加速設計週期。我們也注意到——這點我們在最近的一集節目中也曾談到——設計週期正面臨加快設計速度的壓力，我認為原廠製造商（OEM）和一級供應商的競爭環境正變得愈發嚴峻。 如果這些技術能壓縮設計週期，不僅能提升競爭力、節省成本，而且——正如你所說，隨著軟體程式行數不斷增加，這龐大的複雜性確實需要妥善管理。我認為必須採取「分而治之」的策略才能讓這一切運作順暢。否則，若將其視為一個龐大且單一的系統，根本無法進行驗證。

汽車召回造成 400 至 500 億美元的損失

斯特法諾：絕對沒錯。此外還有其他優勢。所以「左移」絕對是必要的。這能提升程式碼品質，因為你可以更廣泛地進行測試。這點絕對非常、非常重要。 試著想想汽車產業的情況。時至今日，我們每年仍因召回而損失 400 億至 500 億美元。其中 70% 是由於軟體故障所致——這是已記錄案例中的 70%。試著想想這一點。這算是不良品質吧？我們可以這麼說嗎？

約翰：嗯。

斯特法諾：測試結果不佳。

約翰：絕對沒問題。

斯特法諾：不是向左移動。

約翰：嗯。

斯特法諾：對吧？所以向左移，就能降低成本、提升品質。但我也很想考慮到最終使用者。因為我們看到的是，如果不需要將這些電子控制單元（ECU）送出去開發，就能在雲端上實現協作。這點非常重要。事實上，這是 SDV 的一項令人驚訝之處。我們之前討論過基於車載通訊技術（telematics）的 ADAS／AV 服務，也就是車載通訊服務。

利用雲端開發車輛人機介面 (HMI)

斯特法諾：我們看到雲端環境中的人機介面（HMI）開發、人機互動、使用者介面及使用者體驗都呈現出巨大的增長。對我來說，這實在太棒了。而你會立刻明白箇中原因。 你會明白箇中原因，因為這是首度在雲端擁有虛擬電子控制單元（ECU），並能在瀏覽器中呈現使用者介面。由於雲端具備全球覆蓋性，我能立即將它展示給全球各地的合作夥伴網絡。因此，我可以詢問日本或南非的同事：「根據你們當地的偏好，你們對我的新使用者介面有什麼看法？」或者「你們能否加以調整？」又或者「你們能否參與開發？」

約翰：還有在地化、語言。

STEFANO：若您想想看，不再需要隨處部署這些硬體設備，這對人機介面（HMI）系統的開發方式而言，簡直是一場革命。而是採用我們所說的「雲原生、雲優先」的 HMI 開發方法。我們已經有一位客戶正在嘗試採用這項技術。 此外，我們最近也與 BMW 合作，在柏林舉行的 AWS 峰會上發表了一場非常精彩的演講，內容關於他們在雲端進行 HMI 開發的實務做法，當然我們可以提供相關參考資料。這是一場精彩的示範。不過，我們並非總是只談論 BMW；舉例來說，我也可以談談我們在 CES 上與 Marelli 共同進行的示範。Marelli 是一家一級供應商。 他們在我們的展位上展示了首個雲原生 HMI 系統。這真的很棒，因為您可以看到我們是在雲端開發 HMI 應用程式，然後部署在義大利的米蘭。當時是由一位工程師在雲端進行開發，接著將系統部署到拉斯維加斯的展位上，對吧？同樣地，您從雲端開發開始，然後在特定的硬體解決方案上進行部署和客製化，對吧？ 仔細想想，這真的、真的非常強大。這不僅僅是強大而已，這正是 SDV（軟體定義車輛），對吧？它是軟體定義的。否則，若從硬體開始，那就是硬體定義的；若要真正實現軟體定義，就必須從軟體著手，之後再進行部署。

SDV 可降低召回成本

約翰：沒錯，沒錯。你剛才提到了很多重點。而且我覺得，我不希望忽略你剛才提到關於召回的那一點。 我們經常聽到原廠製造商（OEM）表達的擔憂——他們確實背負著沉重的軟體開發負擔——他們常說：「唉，要導入這項軟體定義的車輛功能實在太困難了。」但當你思考這個數字時，就像你所說的，400 億、500 億美元，其中許多都與軟體相關。若不導入能夠應對這項挑戰的功能，那簡直是瘋了，因為只需投入微薄的資金，就有可能節省數十億美元。

斯特法諾：沒錯，我們和康迪公司的馬丁·施塔姆一起錄製了一集非常精彩的《All Things Automotive》。

約翰：是的，我看過那集了。

斯特法諾：對，你看到那段了嗎？就是他解釋為什麼會那樣的那段，對吧？

ECU 的整合

斯特法諾：傳統上，製造商（OEM）總是有需要整合新功能。這意味著，我們得再整合一個電子控制單元（ECU），然後再一個、再一個，直到總數達到 150 個為止。但若考慮到其中的組合效應，你永遠無法測試所有可能的組合情境。 正因如此——這對該產業而言是件好事——在電動化及其他趨勢的推動下，著名的 CASE 概念（即聯網、自動駕駛、共享與電動化，再加上使用者體驗）正推動著這股整合浪潮。這種整合正在發生。

有效整合軟體，避免功能臃腫

斯特法諾：老實說，這對該產業而言確實是一大福音，畢竟當前的課題在於將分散式系統中的軟體進行轉型，並整合到這些整合單元中。但是——這裡有個「但是」——因為關鍵在於不能只是說：「好啦，現在這個 ECU 裡有軟體了，我就直接把它拿來塞進我的整合單元裡。」 那樣就是臃腫軟體。你知道的，那簡直是瀕臨爆炸的狀態。你必須重新架構系統，因為整合單元與那種以成本優化為導向的單一 ECU 截然不同。而且就資源而言，那裡的軟體其實是專為那種近乎客製化的硬體所設計的。 這就是為什麼我們看到這麼多——你也知道的，對吧？——我們所做的工作，例如與 Autoware Foundation 合作開發的 Open AD Kit，就是為了將那套軟體（在該案例中是自動駕駛系統，這類系統傳統上屬於單體式，也就是我們所說的「單體」），拆解成微服務，並重新架構，使其能由真正需要更高模組化與靈活性的硬體與軟體平台所支援。 增量更新，對吧？介面的標準化。而所有這些都是重新架構整個汽車產業至關重要的概念。

SOAFEE 與汽車產業標準

約翰：你知道嗎，你剛才提到的內容，與我們最近和羅伯特·戴關於 SOAFEE 的討論有很強的協同效應。關於 SOAFEE，我知道亞馬遜是該組織的創始成員之一，所以你們對此非常支持。該組織的許多努力，正是為了提供你所提到的那些標準，以及那些一致的介面。不過，這或許是下次再討論的話題。

斯特法諾：是的，絕對沒錯。順帶一提，這真是場內容豐富的對話，我認為 SOAFEE 是一項非常棒的倡議。如果你有看過相關資料，會發現 SOAFEE 的宗旨是基於開放標準與開源技術，提供參考實作。 哎呀，汽車產業真的非常需要開放標準和開源技術，對吧？正因如此，像 Yocto、COVESA、Eclipse SDV、AUTOSAR 這樣的計畫才顯得極其重要。而我們在 SOAFEE 中觀察到的一個非常積極的跡象，就是我們開始攜手合作了，對吧？我們必須堅持這一點，對吧？ 確實，因為開放標準是關鍵，你不會在標準上競爭。那、那是不行的，對吧？你競爭的是——當標準定義完成後——你可以開始進行創新，針對客戶真正、真正需要和想要的事物，而這些並非標準本身。誰會說「啊，對，我要買這輛車，因為這個標準被完美地實現了」？這根本說不通。對吧？

約翰：沒錯。重點在於以標準為基礎，在此之上實現具附加價值的差異化。

斯特法諾：作為基礎。沒錯，這確實是另一種節省成本、進行優化的方式。畢竟，何必在一個普通功能上花費時間和金錢來追求差異化呢，對吧？

約翰：若您喜歡這集節目，我誠摯邀請您為本集按讚，並請訂閱我們的頻道，以在The Garage 觀看更多內容。我們大約每兩週拍攝一集，期待您在下一集節目中再次光臨。

主題 4：機器學習與分析

約翰：史蒂法諾，我們已經談到了許多不同的領域，接下來我想談談人工智慧、機器學習，以及更廣泛的數據分析，因為我們之前討論過我們所彙整的這個令人驚嘆的數據湖，也談到了你們在特殊運算類型中提供的專業服務所具備的運算能力等等。 還有原型開發的重要性等等。但整個機器學習與分析領域，或許是最引人入勝的——這些技術的結合，能夠實現前所未有的突破。

斯特法諾：絕對是。而且這總是從我們所謂的「大迴圈」這個角度來看，對吧？這點非常重要，因為你聽得沒錯，科學家們經常說，在建立正確的模型時，資料集是最重要的，對吧？所以在此過程中，我們總是將此作為參考依據。因此，選擇正確的資料儲存於雲端。

使用 SageMaker 進行資料蒐集與標註

斯特法諾：所以，我們需要在汽車中加入一點人工智慧，才能根據當下的情況判斷哪些資訊是相關的，對吧？也許你曾緊急煞車過。那為什麼會這樣呢？或者是有多種因素綜合造成的。還有車載測試這部分，我們現在就來討論這個超級重要的功能。 但總之，當資料被選取後，其中需要一些機器學習來自動更新，對吧？我們傳送資料、收集資料、清理資料、整理資料湖，完美。接著我們利用部分資料來標註其中一部分，對吧。 因此，我們的客戶會根據自身需求進行標註，我們提供名為「SageMaker Ground Truth」的工具來協助執行這項工作。當標註完成後，我們便利用這些標註資料來訓練和驗證模型。在此過程中，我們有各種選項可供選擇，而 SageMaker 正是我們執行這項工作的平台。

AWS 中的其他機器學習框架

STEFANO：如果你真的是機器學習領域的深度專家，你可以使用像 PyTorch 這樣的基本框架，並真正深入到底層；或者，你也可以使用我們所說的「AI 」服務。例如，像圖像辨識這類服務，你只需傳送一張圖片，就能獲得其中的物件清單。沒錯，還有像AI 這樣的文字轉錄服務。因此，我們有這三個層級。

新車型的車上驗證

斯特法諾：當您透過 SageMaker 訓練模型時，通常會將其部署在邊緣裝置上，但這又是一個大循環。也就是說，模型雖然已部署，但尚未投入生產環境，目前僅用於車載測試。 該軟體還有另一個版本目前已投入生產環境。因此第一階段是分析這個模型相較於生產環境中的版本，表現是較差還是較佳，並將其置於真實環境中進行測試，可能涉及大量實際行駛中的車輛，因為我們受限於運算資源。在這裡，我們有稍多一點的運算資源，可以進行額外的運算作業。

找出邊界情況

斯特法諾：沒錯，就像你之前說的，目的就是為了找出那些特殊情況——也就是所謂的邊緣案例——這些情況不可能僅在開發初期以抽象的方式預先設想，你真的需要有實際的車輛，而且是大量的車輛，才能驗證機器學習模型的效能。 當你進行評估時，如果發現模型表現更佳且沒有退步，就會切換至該模型並將其投入生產，然後這個循環就持續下去，對吧？ 而且會應用在越來越多的車輛上，對吧？由此可見，機器學習不僅僅是一種神奇的訓練方法，它其實是一個智慧的循環。定義工作流程非常重要，而我們擁有許多工具來管理這些工作流程，其中一些就內建於 SageMaker 本身。

用於管理機器學習工作流程的工具

STEFANO：還有其他一些工具，例如在資料管理方面，我們提供 Airflow 的實作與託管服務，這稱為「Apache Airflow 託管工作流程」。我們利用它來組合所有這些工作流程，對吧？我在之前的工作中也用過 Airflow，它對於組合這類資料管線非常強大。對吧？而這正是其中非常、非常重要的一部分。 總而言之，我們的客戶經常將這些功能整合到所謂的「工作檯」中，對吧？越來越多的客戶要求我們提供一個瀏覽器環境，讓他們能在其中找到所需的工具。這些工具可以是資料管線、工作流程、與機器學習相關的資料、資料湖的存取權限，或是產業專用工具。例如，最近我們在 dSPACE 活動上展示了一項與 MathWorks 合作的成果，就是與該平台進行整合。 因此，您可以在該空間中找到這些工具。這讓您能夠高度專注，同時享有環境的一致性、全球分佈、全球存取權限，以及整合與建立自動化流程的可能性。 最近，我們的執行長在 LinkedIn 上發文指出，豐田汽車透過這種做法，每年節省了 1,000 萬美元。這成果相當不錯，對吧？僅僅是將工具進行系統化整理，並透過共通介面呈現，同時還能藉此建立自動化流程。

約翰：我認為你所說的這點很有意思，因為其中包含幾個不同的面向：首先是從數據出發，也就是原始數據；其次是具備建模、調校及優化模型的能力。接著，一旦具備這些能力，在雲端環境中，各種不同的工具和模組便能相互串聯，進行後處理與後分析。而這類工具和模組的種類非常多樣。因此，我認為這個完整的循環流程確實至關重要。

斯特法諾：絕對沒錯。正因如此，例如我們透過自動駕駛資料框架（這是一項開源計畫）來組織並公開相關內容，試圖將開源參考資料交到客戶手中，讓他們能建立這類架構和工作流程。 而且，老實說，我們的客戶確實大多是以這種方式採用這套工具，從工作流程的角度來看，像豐田這樣的客戶，例如就會使用我們的 P 實例，純粹是為了連線至我們的運算環境並參與討論，對吧？藉此在 AWS 上訓練模型。但再強調一次，這並非單一且孤立的活動，而僅是工作流程中的一部分。這一點非常重要，必須納入考量。

主題 5：ADAS 與自動駕駛

約翰：或許現在正是轉入我們最後一個議題的絕佳時機，那就是先進駕駛輔助系統（ADAS）與自動駕駛——這是我們共同投入數年心力、且累積了豐富經驗的領域。 讓我們來談談雲端技術對 ADAS 演進的重要性——我甚至會說它是不可或缺的——同時也探討這段我們共同踏上的邁向自動駕駛之旅所蘊含的潛力。這雖是一段漫長的旅程，但我們正穩步前進。

斯特法諾：絕對沒錯。而且，我再次強調，我對此充滿熱情——我們之前也已經討論過這一點——我非常熱衷於為自動駕駛、自動駕駛功能，以及一般車輛的自動化技術提供一種循序漸進的解決方案，對吧？

ADAS 帶來的短期效益

斯特法諾：因為現在透過 ADAS 系統——例如 L2、L3，也就是所謂的第二級、第三級自動駕駛——你能獲得巨大的價值。這點非常重要，因為首先，它們能拯救生命。就是這麼簡單。對吧？所以我們最近測試了搭載最新一代 ADAS 的車款，表現非常出色。 這輛車確實配備了自動緊急煞車系統。舉例來說，如果你分心了，而前方出現障礙物，車輛就會自動煞車。雖然原理很簡單，但只要能正常運作，就能拯救生命。所以對我來說，這是至關重要的一環。而且我越來越確信，自動駕駛將是這些功能的集合體，這些功能將會逐步實現自動化，對吧？ 因此，除了這些功能之外，思考並規劃未來將在車輛中逐步自動化的增量功能，也是至關重要的。這就是我的觀點。至於我們在雲端運算方面的做法，再次強調，運用我們先前討論的所有內容——基本上包括多樣化的運算選項、資料湖的可能性、資料湖的架構，以及機器學習工具——這些都是 ADAS 和自動駕駛車輛開發所必需的基礎要素。 關於運算選項還有另一個層面，基於 ADAS 特有的兩項原因，這點極為重要：通常您會從實地收集數據，並將數據儲存於 S3 中的資料湖中。接著您會將其用於驗證，對吧？因此，您通常會將從車輛收集的數據重新播放至正在開發的演算法中，以評估其表現是優於還是劣於前一代演算法。 或者，您也可以利用運算資源進行合成模擬。我們與 Valeo 合作有一個絕佳的應用案例，原本打算在因 COVID-19 而取消的 CES 展會上展示——可惜那場展會沒人參加——但我們仍準備了這段精彩的示範影片，YouTube 上有影片，我們當然可以提供連結。在影片中，您可以看到 Valeo 運用兩項技術：一是 IPG CarMaker，另一項是 Foretellix，用來 透過合成模擬來大幅增加情境數量，並在 AWS 上將其擴展至數千種不同情境變體，因為 AWS 具備可擴展性、運算彈性以及運算可用性，藉此真正試圖涵蓋所有這些邊緣案例，以探索我們的分析中是否有所遺漏，本質上就是這樣，對吧？

尋找邊緣案例

斯特法諾：並試著將問題的解決時機「向左移」——如果可以這麼說的話——正如我們先前討論的那樣，在軟體實際部署到車輛之前就解決這個問題，對吧？所以，這再次涉及重新建構這些工作流程，而在 AWS 中，我們擁有所有工具，能讓客戶實現這一點。如果沒有合適的工具，我們也很樂意與客戶合作來開發這些工具。

自動駕駛的分解分析

約翰：絕對是這樣。我認為很多人可能以為自動駕駛是一項整體性的任務。但事實上，它包含許多、許多子任務。我常開玩笑說，有「自行車辨識」任務，還有「車道保持」任務。不過玩笑歸玩笑，實際上確實有許多不同的子任務。你必須將這項任務分解開來——你知道的，我們平時開車時，只是開車而已，就這麼簡單。 但實際上，機器學習和人工智慧的處理方式，就是將其分解成不同的部分。而你剛才提到的那點，我認為非常有趣。因為當你思考訓練時，你知道，如果把駕駛當作一個人來想，大多數時候其實相當無聊，你知道的，就是一直往前直行，真的很無聊。 所以，比起那些必須反覆練習的情境，真正的難點在於：雖然可能會遇到急彎或障礙物，但你提到的這點非常有趣——你可以加速產生邊界案例，提供大量邊界案例，讓模型學習的速度遠比在真實駕駛情境中更快。

斯特法諾：絕對、絕對是這樣。這完全正確。正因如此，例如我們之前討論過的，從這個角度來看，微服務非常重要，因為你可能只想更換感知模型，但讓其餘部分保持不變，對吧？所以需要由具備不同技能的團隊，各自負責他們的小部分工作，對吧。 因此，這一點至關重要——要認清ADAS（先進駕駛輔助系統）或自動駕駛車輛開發中存在的不同角色。這點真的非常重要，對吧？沒錯，這確實是個複雜的場景。但話說回來，我們在這方面有很好的參考案例。我之前提到的與大陸集團（Continental）合作的案例正是關於ADAS開發，你會真切地看到，當他們採用雲原生方法時，在節省時間、降低成本和提升敏捷性方面獲得了多大的收益，對吧？ 這正是我們與他們共同開發的這項 CAEDGE 演練的初衷。順帶一提，這同樣是在「軟體定義車輛」的體驗框架下進行的。因此這是一個極佳的參考案例。我們與 Continental 的合作，正是我們開始構思這些架構的起點。這真的是一次非常棒的合作。

AWS 與Sonatus

約翰：作為本次對話的結尾，我想我們不妨花一點時間，談談Sonatus 與 AWS 在哪些領域正展開合作。

斯特法諾：沒問題，我很樂意。因為我在the garage 上看到了一些令人驚嘆的示範——順帶一提，非常感謝你讓我看到這些。 這實在太令人驚嘆了，對吧？我看到的一些功能，例如控制車輛的邏輯，以及根據新情況部署新邏輯，這完全符合我們在 SDV（軟體定義車輛）和大迴路更新方面所討論的內容。所以你真的能看到這些正在發生。看到這一點真的非常棒。而且，沒錯，這是一次很棒的合作。這也是一個完美的範例。 你看，這不只是單純傳送或蒐集資料，而是開始落實這種「資料平面」的願景——沒錯，我們需要蒐集資料，但控制平面同樣重要。因此，要管理這種微邏輯，從雲端到邊緣再回傳，你必須具備某些微邏輯，或許在邊緣端運用一些機器學習，同時也需在雲端執行部分微邏輯或機器學習。 若從整合的角度思考，或是考量到 ARM 核心，這套系統正是我們所說的「雲端到邊緣的連續體」。我認為，你們透過一系列產品來落實這項願景，確實做得非常出色。

約翰： 你知道，非常感謝。我們稍早談到數據，你知道，我們的「Collector」產品經過高度優化，它會蒐集、調整並精心篩選高價值數據，然後將其傳送至雲端，而我們正與你們在這個領域上合作。至於你剛才提到的「Automator」產品——我們最近才推出——它讓我們能將「智慧數據」的概念付諸實踐，進而採取行動，無論是車內或車外的行動。 我們雖然尚未深入探討車輛測試議題，但車輛測試的問題也正變得日益複雜。因此，我們很興奮能以嶄新的方式運用這項技術，例如優化生產工作流程，同時提供更優質的下游服務。您之前提到連網車輛的下游能力，不僅是針對使用者，甚至還涵蓋後續的增值服務供應商。

使用真實 ECU 的重要性

斯特法諾：是的，這點確實非常有趣。而且我注意到這又是一個極其重要的觀點，因為你們是在真正的 ECU 上進行測試。 相信我，這差異極大，因為我總是說，你知道的，當你為汽車開發新的軟體或硬體組件時，必須明白其中 50% 是開發工作，另外 50% 則是 V 和 V [驗證與確認]。以 ADAS 和 AV 為例，我們來做些假設。我認為 ADAS 的比例大概是 20 比 80。 至於自動駕駛（AV），比例則是 1 比 99。對吧？因為驗證與確認（V&V）確實至關重要，而且當你看到程式碼實際在 CPU 上執行時，情況就截然不同了，對吧？這已不再只是基於評估套件、擺在你桌上的原型機，而是會搭載於一百萬輛、兩百萬輛，甚至一千萬輛汽車上的系統。因此，這完全改變了局面。

約翰：你說得對。而且我們非常高興能參與其中——你知道的，到今年為止，我們的技術將應用於數十款車型；到了明年年底，更將應用於數百萬輛汽車。看到這一切真的很令人振奮，這不是原型機，也不是科學實驗，而是真正的量產。 而在真正的量產過程中——也就是所謂的「真刀真槍」——你能學到很多東西。這也讓事情變得更加困難。

斯特法諾：沒錯。 任何身處汽車產業的人都明白，為了符合法規所付出的努力。這可是這個產業的重要環節，對吧？所以你不能像在手機上那樣隨意部署程式碼。對吧？這不是消費性裝置，因為它是受監管的產品，涉及功能安全與網路安全。這些方面至關重要，對我們而言更是舉足輕重。這是我們的首要任務，甚至可說是「零級優先事項」。

摘要

約翰：是的，今天我們談及的話題實在太多，光是我們討論過的各個子主題，就足以進行許多場各為一小時的對話，但今天我們不得不就此結束了。首先，史蒂法諾，非常感謝你今天蒞臨。能邀請你來，是我莫大的榮幸。 今天的對話讓我收穫良多，我總是很享受與你交談，希望你下次還能再來做客。

斯特法諾：我也一樣，謝謝邀請。每次都讓我很開心。我自己也學到了很多。真是太棒了。

約翰：謝謝你，斯特凡諾。在今天的節目中，我們探討了雲端運算的各個面向，特別是從 AWS 的角度出發，討論雲端運算如何為汽車產業及車輛工作流程帶來效益並加以改善。我們從資料開始談起，闡述資料的重要性，以及運用資料的各種方式；接著談到運算能力，以及對不同類型運算服務的需求，用以解決各類問題。 我們談到了原型開發，特別是能在雲端建立車輛功能原型並部署到實車上的能力，這點非常吸引人。我們也探討了機器學習與分析技術，以及如何透過數據分析以多種方式創造價值。最後，我們簡要談到了自動駕駛與先進駕駛輔助系統（ADAS），並強調改善這些系統及優化其運作流程的重要性。這是一場涵蓋範圍廣泛的對話。 希望您喜歡這集節目，我們期待很快能在《The Garage 》的下一集與您再會。非常感謝。