引擎無法發動。以前冷車發動後，冷卻風扇會立刻高速運轉。面對這樣的症狀，人往往想馬上知道原因或該換哪個零件。這次的對象是一輛 2009 年式 Mercedes-Benz W204 C63 AMG。在藉助 AI 推進診斷時，我們最先做的，是把車輛回傳的資訊連同條件一起保存下來。

本連載會把在實車上已確認的內容與尚未確認的內容分開，介紹整個過程。目前，無法發動與風扇異常的原因都尚未確定。第一次的成果，是留下可供下一次診斷使用的原始紀錄，並整理出需要調查的重點。

OBD 能讀到什麼 #

OBD 是 On-Board Diagnostics（車載自我診斷）的縮寫。透過與車輛的電子控制單元（ECU）通訊，可以讀取故障碼、溫度、轉速等資訊。不過，標準 OBD 能處理的項目，與原廠專屬診斷處理的項目需要區分。故障碼、實測值與車輛資訊各有不同的讀取服務，支援範圍也因車而異。（OBD Solutions 服務一覽）

這次連接 PC 與車輛的是 USB 介面的 OBDLink EX。連接後讀取了裝置的型號名稱與韌體回應，確認實物確實是 OBDLink EX。

人與 AI 的分工 #

AI 並沒有站在車前。裝置回傳的數值，與人看到、聽到並回報的症狀，在紀錄上也分開處理。

例如「鑰匙 ON、引擎停止」是讀取溫度與轉速時的重要條件。我們沒有憑猜測鑰匙位置就開始通訊，而是確認現場的回報後才進行。如果沒有量測發動操作的那一瞬間，就不能把停止時取得的電壓當作發動時的電壓使用。這種條件上的差異，會左右之後的解讀。

決定第一次擷取的範圍 #

程式的範圍也事先決定好了。第一次只做轉接器識別與電壓確認，接著讀取標準 OBD，沒有清除故障碼。也沒有進行 ECU 重置、作動測試、編碼或燒錄。為了調查故障狀態，方針是先保留清除前的回應。

「讀取」這個詞需要注意。在這次的標準 OBD 讀取中，我們向車輛傳送了請求訊框，並接收其回應。這與不傳送任何資料的 CAN 被動監聽，在程序上是不同的。

OBDLink 的官方手冊也把轉接器用的命令與傳送給車輛的 OBD 請求區分開來。實作上採用只傳送已許可請求的架構。（OBDLink 官方程式設計手冊）

保留原始紀錄與擷取結果 #

保存的不只是加工成易讀形式的數值。我們保留了傳送的命令、收到的字串與原始位元組序列、日期時間、裝置以及鑰匙狀態，之後再另外產生解碼結果。如此一來，即使日後修正解碼方式，也能回到擷取當時的原始紀錄核對。在畫面上顯示「水溫 21 ℃」，與保存得出該數值的回應，各有各的作用。

我們也決定，不用正常值去填補沒有得到回應的項目。

我們也避免把只收到一部分的回應當成完整清單來解讀。越是把分析交給 AI，就越需要不模糊這些區別的紀錄。

第一次的結果與下一次量測 #

在第一次短時間的擷取中，標準 OBD 正常回應，確認了水溫 21 ℃、引擎轉速 0 rpm 等數值。在有回應的範圍內，儲存故障碼與待定故障碼皆為 0 筆。另一方面，永久故障碼未能取得。僅憑標準 OBD 的結果，無法判斷包含發動許可、照明等在內的整車是否正常。

轉接器讀到的電壓為鑰匙 OFF 時 11.9 V、鑰匙 ON 時 11.6 V。這些是 OBD 接頭端的數值。我們沒有在電瓶端子量測，也沒有取得啟動馬達運轉期間的電壓。它們可以作為下一步確認電源狀態的材料，但還不到僅憑這些就決定電瓶壽命或是否需要更換的階段。

症狀回報也有變化。這次鑰匙 ON 時風扇沒有高速運轉；進行發動操作時，有回報指出啟動馬達短暫轉了一下。以前「完全沒有反應」的回報，作為當時的歷程保留。我們也沒有根據這次引擎停止狀態下的觀察，判斷冷車發動後的風扇異常已經消除。

到此實車作業暫告一段落，決定下次先把電源狀態整頓好再繼續確認。原廠專屬診斷的程式也已準備，但以模擬回應進行的測試與實車擷取是分開的。程式通過測試，並不能證明已與這輛車的各控制單元通訊成功。

藉助 AI，資料整理、通訊處理的實作與紀錄比對都更容易推進。支撐這些判斷的，是在現場確認的條件與未經加工的回應。

下一回，我們將依照擷取結果，看看如何解讀第一次的紀錄、弄清了什麼、還有什麼不清楚。