「正常運作時間方程式」：為何車載平台不能坐等雲端服務

這是《正常運作時間方程式》的第 3 部分。 第 1 部分 探討了車輛情境，而 第 2 部分 探討了硬體與軟體之間的權衡。本部分則探討工作應在何處執行。

一輛長途貨車行經一段行動訊號中斷的高速公路路段。在這段路程的某處，出現了一項持續 90 秒、隨後消失的間歇性電路故障。若偵測工作仰賴雲端，則會發生以下兩種情況之一：要麼錯過該事件，要麼在相關訊號已被覆寫後，才收到延遲傳來的快照。下次問題再次發生時，可能是在維修廠，而該廠並無先前導致此問題的狀況紀錄。

這是文中所述「再驅動問題」的實地版本 《代理迴路》一文中所述的「再驅動問題」之實地版本。在商用車輛中，此現象發生得較為頻繁，這是由於這些車輛的行駛地點與運作方式所致。

連通性並非理所當然

覆蓋範圍地圖的預測較為樂觀。在一份 2019 年美國聯邦通信委員會（FCC）工作人員調查中，現場調查員在 12 個州進行了 24,649 次路測，總里程近 10,000 英里。其中僅有 62.3% 的測試結果達到電信業者地圖所預測的下載速度。雖然自 2019 年以來網路品質已有所改善，但這個教訓依然適用：一張顯示訊號覆蓋範圍的地圖，並不代表卡車在發生故障的當下一定能接收到訊號。 礦場、農場、建築工地及港口的非公路設備，往往運作於訊號覆蓋規劃者鮮少優先考量的區域。車隊早已針對此情況制定應對策略：駕駛員會等到抵達停車場才傳送行車紀錄，技術人員則在卡車進場時手動擷取數據，而卡車在行駛途中失去訊號，通常被視為正常現象而非警訊。每種應變措施都會犧牲運作時間，且這些方法都無法偵測到在空曠高速公路路段上持續90秒的故障。

這種不確定性使得離線運作成為一項設計需求，而不僅僅是備用方案。在麥肯錫關於 汽車領域邊緣AI 的調查中，39% 的受訪者指出離線可用性是所有AI 應用場景的關鍵要求，其重要性高於低延遲（35%）以及資料隱私與安全（20%）。僅有 6% 的受訪者提及網路資料成本。邊緣運算的價值不在於節省行動數據費用，而在於處理那些雲端無法觸及的資料。

流量：問題在於信噪比，而非數據費用

商用車網路會持續產生數據。單一 SAE J1939/14 匯流排的傳輸速率最高可達 500 kbit/s，許多重型卡車配備多條此類匯流排，而新款平台更新增了汽車乙太網路，其中大部分用於傳輸 ADAS 及安全系統所需的攝影機影像。在整整一天的行車過程中，這些數據遠超過值得傳輸的量，而其中大部分僅是確認一切運作正常。

作為 「代理迴路」 所闡述的，持續記錄資料「透過行動網路傳輸成本高昂、儲存成本高昂，且處理成本高昂」。另一種做法是在車輛端決定哪些資料才是重要的：

• 事件觸發式擷取。 記錄事件發生前與發生後的訊號，而非全天候持續記錄所有訊號。透過Fastlane™ Edge Smart Triggers，例如，車輛上的輕量級異常偵測模型僅在偵測到異常行為（例如引擎運轉超出正常範圍）時，才會啟動Fastlane™ Collector 策略，因此車輛僅擷取異常事件周邊的訊號，而非持續性的訊號流。
• 車載壓縮。 Fastlane™ Collector 指出透過時間序列壓縮，可將資料有效載荷大小減少多達 28 倍。
• 車載歷史紀錄。 車輛上的時間序列資料庫會保存最近數週或數月的訊號歷史紀錄。若在訊號中斷區發生故障，當卡車重新連線時，相關背景資料仍會保留，工程師便能直接調取所需的精確時間區間，無需等待故障再次發生。
• 上傳前進行篩選。 傳送摘要且相關的結果，而非原始資料流。在某個 合作夥伴案例研究 中，針對車載入侵偵測，透過在地處理並僅上傳相關警報，成功將雲端成本降低 60%。

延遲：有些決策不容耽擱

某些操作——例如保護組件、調整系統運作、向駕駛人發出警示，或是標記可能的網路入侵——必須在幾秒內完成。這使得車輛成為處理這些操作的自然場所，儘管延遲本身並不能決定智慧處理應在何處執行。麥肯錫指出，邊緣運算並不總是能提供決定性的延遲優勢。對於許多診斷應用情境而言，可用性與情境因素比毫秒級的延遲更為重要。

這一切並未降低雲端的重要性。它能完成單一車輛無法完成的工作：

• 車隊範圍內的模式偵測。 某種故障模式在單輛卡車上可能僅呈現為雜訊，但在數千輛卡車上卻可能成為顯而易見的問題。
• 根本原因調查。 該流程將車輛數據與工程文件、維修紀錄及過往案例相互結合。 Fastlane™ Insight 該系統透過雲端運作，利用「AI 」將這些資料來源相互關聯，並提出可能的根本原因建議。
• 模型訓練與驗證。 此過程利用在邊緣裝置所擷取的、富含情境資訊的事件。
• 分發。 更新的模型與資料收集政策會透過無線方式推送至車輛。

邊緣裝置負責偵測與擷取資料，雲端則進行推理與學習，隨後邊緣裝置根據雲端所學的結果採取行動。 Fastlane™ Edge 該系統正是圍繞這個循環建構而成：它在車輛上執行異常偵測，並隨著雲端持續學習，透過無線方式接收更新的模型。在邊緣端運行智慧處理功能，可降低對連線能力的依賴；而透過車隊範圍內的學習，則能持續改善已上路行駛的車輛。

劃清界線

一條實用的準則：將工作安排在資料和截止日期所在之處。

如果某項決策取決於某輛車當下的數據，該決策應由車輛處理；如果取決於多輛車隨時間累積的數據，則應由雲端處理。在車輛端擷取情境資訊，對於混合車隊也大有幫助。當數據在來源端採用共享訊號定義（例如 COVESA VSS等，這些資料便能以相同格式從各品牌傳送至車隊的車載資訊服務供應商。市場預測顯示，原廠製造商正積極投資此模式。 GM Insights 估計，到 2025 年，商用車將佔汽車邊緣運算市場的 35.9 億美元，年成長率約為 22%。

一旦邊緣裝置擷取到正確的背景資訊，這些資料便會成為「AI 」的原始素材，使其能夠預測故障，而非僅是通報故障。第四部分將延續這個主題。

總而言之： 商用車需要在連線的兩端都具備智慧能力。車輛負責偵測、情境擷取以及時效性關鍵的行動。 雲端則負責整個車隊的學習任務。建議：將這些任務預設交由車輛處理，並將雲端保留給任何需要多於一輛卡車數據的任務。從一開始就將兩者設計為一個閉環，讓在雲端訓練的模型回流至最初擷取數據的卡車。卡車未能偵測到的故障，最終仍會反饋回來，而每次故障反饋都會消耗正常運作時間。