BESTNET TECH BLOG
區分轉接器的通訊功能與車型專屬診斷定義，把原廠診斷程式作為尚未經實車驗證的準備階段整理好
即使能透過標準 OBD 與車輛通訊，也不代表故障診斷就此完成。對於這輛 2009 年式 W204 C63，除了標準 OBD 取得的資訊之外，我們還希望確認 SAM、EIS、ESP 的資訊。於是，我們推進了使用手邊 OBDLink EX 進行原廠專屬診斷的準備工作。
目前完成的是讀取程式與離線驗證。尚無在這輛車上讀到 SAM、EIS、ESP 的實績。
SAM 是指訊號擷取與作動控制單元，EIS 是指電子點火開關，ESP 是指車身動態穩定系統。目的是確認這次標準 OBD 沒有調查的這些系統的狀態。
準備工作的進度 #
| 項目 | 狀態 |
|---|---|
| 讀取程式 | 已撰寫 |
| 離線驗證（模擬回應） | 51 項通過 |
| EIS、ESP 的通訊路徑 | 源自其他車輛的候選 本車尚未驗證 |
| SAM 的通訊路徑 | 未確定 從識別開始確認 |
| 在本車上的實際讀取 | 下一回 |
轉接器的規格與車型專屬診斷定義 #
首先整理的，是轉接器的通訊能力與車型專屬診斷定義之間的差異。即使有能連接 CAN 的硬體，傳送到哪個目標、使用哪種協定、請求什麼內容，仍需另外掌握。還必須了解回傳資料的格式與意義。僅憑「裝置支援 CAN」這項資訊，不能判斷能夠診斷特定年式的 SAM。
在 OBDLink 的官方資料中，可以確認在 CAN 上傳送分段訊息的 ISO-TP、接收過濾器以及流量控制的設定。這些是建構讀取處理的基礎。另一方面，各車型的 ECU 位址表與故障碼說明，並無法從該資料取得。這次我們同樣把硬體規格的確認與車輛通訊定義的調查分開進行。（OBDLink 官方規格）
從其他車輛的資料準備候選 #
EIS 與 ESP 的候選，使用的是原開發者公開的 2011 年式 C207 通訊紀錄。其中保留了具體的收發路徑、診斷工作階段，以及對故障碼請求的回應。但它的對象與這次的 2009 年式 W204 C63 不同。資料中有實測值，與該設定是否適用於手邊這輛車，是兩項不同的確認事項。實作中也保留「候選」標籤，預設不執行。（MBLINK 公開定義、C207 回應紀錄）
公開紀錄的格式也有其限制。其中記錄的是整理後的診斷訊息，並不是 CAN 原始訊框本身。僅憑該紀錄，無法斷定分段通訊的控制資訊或是否使用延伸位址。下一次需要保存實際回應，不只核對目標位址，也要核對訊框格式。
關於 SAM，前後兩個都尚未找到可用於這輛車的確定路徑。我們沒有直接套用其他車型的位址，而是先設置取得識別資訊的階段。設計上利用公開資料中候選路徑的規則，每次只確認少量。通常一次以 6 個槽位為對象，並未做成自動逐一嘗試全部 47 條路徑的動作。候選的數量並不代表已實測的模組數量。
傳送到未識別路徑的，只有固定的識別請求。即使有回應，也不會由此自動擴展到讀取故障碼或切換工作階段。確認回傳的識別字串與其他依據後，才反映到車輛用的定義中。如果沒有回覆，仍需確認目標位址、協定、電源狀態等。僅憑無回應，不能斷定 SAM 故障。
區分回應的狀態 #
即使能夠接收，結果的分類也很重要。我們把故障碼正常回傳 0 筆的情況與未能取得的情況分開。NO DATA、否定回應、等待回應、中途截斷，均依各自的狀態原樣記錄。
UDS（Unified Diagnostic Services）是 ECU 與診斷器交換資訊所用的診斷服務。在其故障碼回應中，我們依長度檢驗代碼與狀態資訊是否成對。即使看到像故障碼的數值，只要缺少最後的狀態資訊，就不當作完整結果採用。
這種區分在審查 AI 產生的處理時也很有幫助。我們使用在正常空清單中混入 CAN 錯誤的模擬回應，驗證不會被判定為 0 筆。架構上先判斷通訊錯誤，保留原始資料並中止擷取。在產生易讀的摘要之前，需要先確認回應是否有效。對於無法確認意義的原廠專屬代碼，我們沒有附加推測性的說明。
執行條件與離線驗證 #
另外，即使是「唯讀」，也會向車輛傳送請求。標準 OBD 同樣是請求資訊並接收回應的通訊。接收分段回應時，也會傳送必要的流量控制訊息。在這次的設計中，讀取請求是固定的，清除 DTC、ECU 重置、安全存取、寫入、作動測試等都沒有列入許可清單。切換診斷工作階段需要另外明確指定，且僅限於有資料可依的 EIS 與 ESP 候選路徑。
下一次的實車模式需要鑰匙 ON、引擎停止、穩定的電源，以及執行候選的指定。程式會核對所連接的裝置與目標車輛，並在途中持續確認電壓。預設的電壓下限 12.0 V 與追加請求的時間上限 30 秒，是本程式設定的停止條件，不能作為原廠的維修規範值引用。即使條件不滿足，也依設計保留到途中為止的證據。
到目前為止通過的 51 項測試，是使用記憶體中的模擬裝置與回應進行的離線驗證。在這次原廠診斷準備中，傳送給實車的請求為 0 筆。我們確認了對分段回應、目標不符、電壓下降、禁止請求、中途截斷等情況的處理，但這些並不是證明 Windows 實際連接埠收發以及 W204 原廠診斷成功的測試。
藉助 AI 推進的，是資料整理、候選的實作，以及包含異常回應在內的驗證。接下來要確認的是：候選路徑在實車上能否成立、是哪個 ECU 在回覆、能否正確組合回應。只有結果齊備的項目才會採用到車輛設定中，未確定的項目將繼續以未確定處理。
