標準OBDで車両と通信できても、それだけで故障診断が完了するわけではありません。今回の2009年式W204 C63では、標準OBDで得た情報に加えて、SAM、EIS、ESPの情報を確認したいと考えました。そこで、手元のOBDLink EXを使ったメーカー固有診断の準備を進めました。

現時点で完成したのは、読取プログラムとオフライン検証です。この車両でSAM、EIS、ESPを読めた実績は、まだありません。

SAMは信号取得と出力制御のユニット、EISは電子イグニッションスイッチ、ESPは車両の横滑り防止制御を指します。今回の標準OBDでは調べていない、これらのシステムの状態を確認することが目的です。

準備の到達点 #

アダプタの仕様と、車種別の診断定義 #

最初に整理したのは、アダプタの通信能力と、車種別の診断定義の違いです。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が返答しているか、応答を正しく組み立てられるかです。その結果がそろった項目だけを車両用の設定に採用し、未確定の項目は引き続き未確定として扱います。