感測器原始資料注入是什麼？ADAS 測試從物件下探到像素

ADAS 的 ECU 測試有一條分水嶺：你餵給它的是「物件」還是「原始資料」。重播 CAN 上的物件清單（前方有車、距離多少）只能測決策邏輯；感知演算法本身——從像素與回波裡把那台車「看」出來的部分——完全沒被碰到。要測感知，就要把攝影機的影像流、雷達的原始回波、光達的點雲在感測器介面的層級餵進去，這就是原始資料注入（Raw Data Injection）。

注入點決定你測到什麼

同一顆 ECU，資料可以從三個層級進去：

原始資料層是性價比的甜蜜點：感知演算法被完整覆蓋，而環境可以完全數位化。實作上要對齊真實的感測器介面——攝影機常見的序列化介面（如 FPD-Link、GMSL 家族）、雷達透過量測介面取原始資料、光達多走乙太網 UDP——注入設備必須以正確的介面、正確的時序把資料打進去，這是專用串流硬體存在的理由。

開迴路與閉迴路：重播的極限

開迴路（重播實錄資料） 適合迴歸：同一段路、同一批像素，版本 A 與版本 B 的輸出可以嚴格對比。但它有個天生極限——受測系統的決策改變不了輸入。如果新版本提早煞車，錄好的影像仍然照原速前進，因果就斷了。

閉迴路（模擬環境即時生成） 解決這件事：DYNA4 這類物理級模擬把車輛動力學、交通參與者、天氣光照全部參數化，感測器模型即時算出對應的原始資料餵給 ECU，ECU 的控制輸出再回到模擬改變車輛狀態。「雨天黃昏、前方機車突然切入」變成一組參數，要跑幾百次就跑幾百次，每次都因 ECU 的反應不同而演化出不同結果。

閉迴路的品質瓶頸在感測器模型的保真度：幾何對了只是及格，雷達的多路徑、攝影機的眩光與雜訊、光達在雨中的衰減，這些「不完美」正是感知演算法的難點所在——模擬裡沒有這些，測試就偏樂觀。務實的做法是明確劃界：哪些缺陷模型有覆蓋、哪些留給實車與實體激勵層。

多感測器同步：微秒級的較真

感知融合假設各感測器的資料在同一個時間座標上。注入端如果攝影機流與雷達流各走各的時鐘，漂移累積起來，融合演算法看到的是「幽靈時差」——測出來的問題其實是測試環境自己製造的。工程要求很明確：

• 所有注入通道共用同一時間基準（PTP 這類精確時間協定）
• 資料的時戳在生成端打，不是在注入端補
• 同步品質本身要被監控與記錄——它是測試有效性的前提條件

SIL 與 HIL 共用場景資產

同一套場景（道路、交通、天氣參數）應該同時服務兩個階段：SIL 階段純虛擬大量並行掃參數空間、HIL 階段配上真實 ECU 與原始資料注入驗證時序與介面（分工邏輯見 HIL 測試是什麼）。標準化介面（如 ASAM OSI）讓場景與模擬器解耦，換階段不重建場景庫——幾百個邊緣案例的資產，值得這樣保護。

下一步

從注入層級選擇、串流硬體到閉迴路場景庫的建立，歐特莫夫（Vector Informatik 合作夥伴）協助建置虛實整合的 ADAS 驗證平台。

• 📄 解決方案：一站式 ADAS 測試平台：含 HIL 模擬與實車驗證方案
• 📬 預約一次現況盤點