UDS / DoIP 車載診断入門

UDS では、やりたいことごとに SID（Service Identifier） が割り当てられています。代表的なものは、診断セッション制御（10h）、ECU リセット（11h）、セキュリティアクセス（27h）、データ読み出し（22h）、データ書き込み（2Eh）、DTC 読み出し（19h）、ルーチン制御（31h）、ダウンロード要求（34h）、データ転送（36h）です。

ECU 側は、要求されたサービスを受理するか、否定応答（7Fh）に NRC（Negative Response Code）を添えて拒否理由を返します。実装のバグは、この NRC の使い方に現れやすい部分です。

UDS は診断セッションという概念を持ちます。デフォルトセッションでは限られたサービスしか使えず、拡張セッションやプログラミングセッションへ遷移して初めて、書き込みやリプログラミングが可能になります。

さらに、危険な操作の前にはセキュリティアクセス（27h）が要求されます。ECU が発行したシードに対して、正しいキーを返せた場合のみロックが解除されます。この鍵アルゴリズムの管理と配布は、実務では設計そのものより厄介な論点になります。

CAN 上で UDS を使う場合、8バイトを超えるメッセージはISO 15765-2（CAN-TP、ISO-TP）で分割転送します。単一フレーム（SF）、先頭フレーム（FF）、連続フレーム（CF）、フロー制御（FC）の4種類で構成されます。

フロー制御のブロックサイズ（BS）と最小間隔（STmin）の設定は、転送時間に直結します。リプログラミングの所要時間が想定より長い場合、まずここを確認してください。

DoIP（Diagnostics over IP、ISO 13400）は、車載 Ethernet 上で診断を行う仕組みです。CAN の帯域では現実的でない大容量のファームウェア転送を、桁違いに短時間で行えます。

DoIP では、車両検出（Vehicle Identification）、ルーティングアクティベーション、そして診断メッセージの送受信という手順を踏みます。UDS のサービス自体は CAN の場合と共通で、下位の運び方だけが変わる、と捉えると理解しやすいです。

実務では、CAN 診断と DoIP を併存させ、対象 ECU やデータ量に応じて経路を切り替える構成が一般的です。

ODX（ISO 22901）は、診断に関する情報を記述する標準フォーマットです。どの ECU にどのサービスがあり、どの DID がどんな意味を持つかを機械可読な形で持ちます。配布用にパッケージ化したものが PDX です。

A2L（ASAM MCD-2 MC）は、測定・校正（XCP/CCP）のためのファイルです。ECU 内部変数のアドレス・変換式・特性マップを記述します。

この2つは目的が異なります。診断は ODX、測定・校正は A2L。ツールを選ぶ際は、手元にある資産がどちらの形式かを先に確認してください。

開発初期は、ECU シミュレーションで診断仕様を先に固めると手戻りが減ります。実機が出てきたら、診断ログの取得と仕様との突き合わせ。量産前には、並列フラッシュによる書き込み時間の検証。サービス工程では、現場向けにカスタマイズした診断ツールが必要になります。

工程ごとに別ベンダーのツールを使うと、ODX 資産の変換で消耗します。同一系列でそろえられるかは、選定時に見ておく価値のある観点です。