耐久車隊跑了三個月回來，硬碟裡是幾 TB 的「全程錄影」。問題來了：那次偶發的儀表警告，發生在哪一天的哪一段？錄得越全，翻得越久——這是連續記錄模式的死穴。車載資料記錄器（Data Logger）真正的專業，不在容量，在觸發。
觸發式記錄：只錄「值得看的片段」
核心概念是把「錄什麼」從時間軸切換成事件軸：平時資料只在記憶體裡流動，滿足觸發條件的瞬間，才把事件前後的一段固化成檔案。觸發條件可以是：
- 訊號條件：某訊號超限、變化率異常、狀態旗標翻轉
- 診斷事件：DTC 被設定的那一刻（故障碼語意見 UDS 那篇）
- 網路事件：錯誤訊框爆量、節點失聯、匯流排負載異常（錯誤訊框機制見這篇）
- 人為標記：駕駛按鈕——「剛剛那個怪怪的」是車隊測試最珍貴的訊號之一
- 組合邏輯：條件 A 且 B、A 之後一段時間內出現 C
環形緩衝：事件「之前」比之後更重要
除錯時真正想看的，是事件發生前系統在做什麼——原因在前面，結果才在後面。但觸發發生時，「之前」已經過去了，怎麼錄？
答案是環形緩衝（Ring Buffer）：記錄器平時就把所有通道的資料寫進一段固定大小的記憶體，寫滿了從頭覆蓋——像行車記錄器的循環錄影。觸發命中的瞬間，緩衝裡躺著的正是「事件前」的完整脈絡，與觸發後續錄的片段接起來，就是一段「前因＋後果」的完整證據。
前段要多長是工程判斷：抓通訊時序問題，前段短一點就夠；抓熱累積、慢漂移類的問題，前段要拉長——觸發條件與前後段長度，應該按「假設的故障機制」設計，而不是全站套同一組預設。
喚醒與休眠：耐久測試的隱形殺手
車隊測試裡最氣人的資料缺口：事件發生在點火後的頭幾秒，記錄器還在開機。網路管理喚醒、開機瞬間的訊息風暴、電壓波動——這些正是問題高發區，卻是慢開機記錄器的盲區。所以記錄器的關鍵能力清單裡，「開機到開始記錄的時間」與容量同等重要；同樣重要的還有休眠喚醒行為：跟著匯流排活動喚醒、安靜後自動休眠、休眠期間不拖累整車靜態電流——記錄器自己變成耗電異常源，是真實發生過的烏龍。
記錄只是起點：資料要回得了家
觸發式記錄解決「錄得準」，車隊規模下還要「回得來、找得到」：
- 遠端組態：觸發條件要能整隊更新——新假設出現時，不能等車回廠一台台改
- 自動回傳：事件片段透過行動網路即時上傳、大宗資料回廠自動卸載
- 狀態監控：整隊記錄器的健康度（在錄嗎？容量？版本？）要有儀表板——資料缺口最常見的原因是「那台記錄器上週就掛了，沒人知道」
- 入庫即可查：片段帶著車輛、版本、觸發原因的詮釋資料入庫，接上訊號級索引（下一步見量測資料為什麼找不到）
下一步
從觸發策略設計、記錄器選型到車隊回傳與監控，歐特莫夫（Vector Informatik 合作夥伴）協助把「錄資料」建成找得到答案的證據鏈。
- 📄 解決方案：車輛資料記錄解決方案：高效能 ECU 診斷與遠端監控
- 📬 預約一次現況盤點