這是《正常運作時間方程式》的第 2 部分。 第一部分 闡述了為何必須在車輛上擷取車輛情境。本部分則探討執行此項作業所需的成本。
某平台團隊開發了一種模型，能在卡車後處理（排放控制）系統發生故障數週前預先預測故障。 工程層面的問題已解決，但平台層面的問題尚未釐清：這個模型該在何處運行？如果它能安裝在卡車現有的閘道器或車載通訊控制器上，就能隨現行生產計畫出貨；如果需要效能更強的控制器，則必須等待下一代電氣／電子（E/E）架構，而這項技術將永遠無法應用於現已上路的卡車。
每當出現新的數據應用案例時，這個問題就會被提出；而在商用車領域，其背後經濟考量與乘用車相比，有以下三點差異。
為什麼卡車的計算方式會有所不同
銷量。2025年美國第8級卡車的零售銷量為 208,386輛。美國輕型新車銷量為 1,620萬輛，約為其78倍。若將中型卡車及專用卡車納入計算，差距雖會縮小，但仍無法完全彌平。每增加一美元的運算硬體成本，以及每花費一美元用於整合與驗證新控制器，所分攤的銷售單位數量僅佔總數的一小部分。
使用壽命。 美國重型卡車的平均 12.1年 。車隊也傾向延長卡車的使用年限：根據 ACT Research 的數據 據《FleetOwner》報導 所引用的 ACT Research 數據顯示，車隊中第 8 級卡車的平均服役年限為 6.3 年，創下自 2013 年以來的最高紀錄。新的運算硬體（例如效能更強的閘道器、車載通訊裝置或電子控制單元）僅能幫助新車款。現有車隊中的車輛往往會沿用出廠時配備的硬體長達十年或更久，而其中大部分的 第一部分所述的 便體現於現有車隊之中。
架構週期。 商用車的電子/電氣（E/E）架構通常以多年為週期進行更新，且許多控制器來自原廠（OEM）無法完全掌控的供應商。與新運算硬體相關的應用案例，其時程安排亦受此週期所影響。
綜上所述，這三個因素讓一個問題變得至關重要：卡車所需的智慧功能中，有多少必須來自新硬體，又有多少可以透過更有效利用現有硬體來實現？車載AI 的資金來源主要有兩種方式。一種是購買功能，另一種則是提升效率。
途徑一：購買能力
硬體的優勢確實存在。集中式與分區式架構將工作負載整合至數量較少、效能更強大的控制器上，並減少布線。麥肯錫指出，由於這些控制器需要更強大的處理能力， 因此會產生額外成本。商用車原始設備製造商（OEM）也正朝此方向發展。 Coretura——這家由戴姆勒卡車與沃爾沃集團於 2025 年成立的合資企業——正致力於打造一個共享的軟體定義車輛平台。該公司還將為商用車指定並採購集中式高效能控制器，預計本十年末前將首度應用於目標車型中。
當工作負載確實需要更強大的運算硬體時——例如高效能的中央控制器或區域控制器，或是專用的AI 加速器——這便是正確的解決方案：無論是攝影機感知、ADAS、自動駕駛，或是任何在車輛使用壽命期間，每輛車所創造的價值明顯高於您當前產量下所增加成本的情況。此外，在設計新平台時採用此方案也合情合理。
但這也有其局限性。根據該平台的時程表，此技術僅適用於新車款。此外，即使控制器更大，也無法取代高效能軟體的必要性，因為在共用電腦上，每個工作負載都會爭奪相同的資源。在麥肯錫關於 汽車邊緣運算AI 的研究中，46% 的受訪者指出系統單晶片（SoC）資源有限是主要障礙。
途徑二：提升效率
軟體途徑能更充分地發揮現有硬體的效能。目前已有幾項技術已臻成熟：
- 模型壓縮。 整數量化可使模型 大小約減少 4 倍，執行速度提升 3 倍 ，且精度損失極小。將修剪與量化結合，可將模型儲存空間 35 倍至 49 倍，且不影響精確度。麥肯錫指出，微控制器越來越能夠在邊緣端執行輕量級的AI 模型。
- 按需執行。 模型可安裝於車輛上，而無需持續運行。如 《始終處於運作狀態的AI 模型對商用車輛資源造成負擔》一文所述一文所述，共享的車載執行環境可讓持續運作或安全關鍵型模型保持運行，並僅在車輛狀況需要時，才啟動其他模型（例如在車廠停泊期間進行的電池健康狀態檢查）。
- 基於事件觸發的資料蒐集與車載壓縮。 車輛僅儲存並傳送與事件相關的資料，而非將所有資料進行串流傳輸。
- 虛擬感測器。 軟體可根據車輛網路中現有的訊號估算數值，而無需額外加裝實體感測器。在某個 合作夥伴案例研究中，透過 CAN 訊號建構的純軟體式頭燈水平調節感測器，使每輛車的硬體成本最高可降低 20 美元。在此案例中，軟體解決方案不僅避免了增加物料清單（BOM）成本，更徹底消除了這項成本。
在卡車領域，軟體路線的最大優勢在於其覆蓋範圍。它可以在不超出車輛運算能力的範圍內，透過無線方式部署至已投入營運的車輛，並在現行系統上直接運行，無需等待下一代架構的推出。這正是 Fastlane™ Edge，該解決方案利用車輛現有的運算資源（例如高效能閘道器、車載通訊單元或中央電腦），在無需專用AI 加速器的情況下，執行AI 模型、虛擬感測器及預測性診斷。對於尚未具備此類運算能力的卡車， Fastlane™ Copilot 則會在原型車和測試車隊中，為現有車輛增設高效能閘道器，且無需變更其量產架構。
但這也有其局限性。軟體無法將閘道器轉變為感知電腦。它受限於運算餘裕、記憶體及驗證工作量，且在安全性、網路安全與生命週期管理方面也伴隨著自身的成本。
把它當作一個決定來處理
錯誤之處在於將硬體和軟體視為獨立的預算項目。軟體的效率高低，決定了您需要多少硬體。平台團隊應遵循的實用步驟如下：
- 先進行優化，再決定硬體規格。 應在完成壓縮與事件觸發式設計後，再釐清工作負載的需求，而非在此之前。
- 問問價值究竟在哪裡。 如果大部分價值在於既有用戶群，那麼硬體路線是無法觸及它的。
- 請根據您的產量，將價值與成本進行比較。 請將每輛車在整個使用壽命期間所創造的價值，與新增硬體及整合成本進行權衡，並將這些成本分攤至您的實際產量中。
- 若新架構即將推出，請預留擴充空間。 規劃時應假設高效的軟體將會填補這部分空間。
軟體也有其相應的成本。每當在卡車上新增一個模型，都需要運算資源、記憶體、整合工作以及驗證，而且必須在車輛的整個使用壽命期間持續維護。透過僅在需要時執行模型，並讓所有模型共用同一個執行環境，就能避免這筆成本隨著每個新應用場景的增加而不斷攀升。
一旦工作負載能部署在裝置上，接下來的問題就是：哪些工作本就該部署在裝置上，哪些則該部署在雲端？這將在第 3 部分中探討。
總而言之： 擷取豐富的車輛情境資料並在車上運行AI 需要成本，而商用車原始設備製造商（OEM）所面對的產量規模，遠小於乘用車製造商。他們可透過兩種方式來負擔這筆成本：增設功能更強大的硬體，並以資料的價值作為投資依據；或是讓軟體效率足夠高，得以在車輛現有的運算資源上運行。多數廠商將同時採用這兩種方法。 然而，低產量、12 年的使用壽命以及漫長的架構週期，意味著車廠應將軟體作為預設方案：在卡車現有的運算資源上執行新的工作負載，並僅在特定情況下（例如相機感知等工作負載需要額外運算能力，或正在設計新的電子/電氣架構時）才增設運算硬體。