はじめての UDS：CAN 診断通信「リクエスト／レスポンス」入門

完全版を表示する

こちらは、CAN通信をある程度理解している方向けの記事となっております。

参考
CAN通信とは？規格やプロトコルについて解説

近年の自動車、産業機械、医療機器、家電製品に至るまで、さまざまな分野でCAN（Controller Area Network）が採用されています。このブログ記事では、CANの規格や動作の仕組みについて ...

続きを見る

本記事の内容は、「CAN通信」の解説記事の「データフィールド」の中身の一種です。

UDSはCAN通信を使った、比較的新しい規格です。一体どんなものなのか、見ていきましょう

UDS が生まれた背景と OBD-II との違い

クルマの電子制御ユニット（ECU）は年々高機能化し、診断項目も桁違いに増えました。従来の OBD-II（SAE J1979） は診断用コネクタの規格と思われがちですが、実際は主に排ガス関連を対象とした規格で、サービス（機能）数は十数個しかありません。そこで各社が独自の拡張フレームを量産して診断ツールが乱立し、混沌としていました。この“混沌”を統一するために ISO 14229 (UDS: Unified Diagnostic Services) が策定されました。

こういった経緯により、UDSは次の特徴を持っています。

  • サービス ID（SID）を 1 バイトで共通化
  • 要求（Request）と応答（Response）のパターンを厳密に規定
  • OBD を包含しつつフラッシュ書き込みやセキュリティまで網羅

こうして「ツール 1 本でメーカー横断的に診断できる世界」が現実になったわけです。

プロトコル階層 ― CAN の上に ISO-TP、その上に UDS

CANは通信規格ですが、UDSを解説するにはいくつかの規格を押さえておく必要があります。まずは階層を見てみましょう。

階層プロトコル役割
物理層CAN 2.0B11/29bit ID、125 kbps〜1 Mbps
ネットワーク層ISO-TP (ISO 15765-2)8 バイトを超えるペイロードの分割再結合
セッション/アプリ層UDS (ISO 14229-1)診断サービスの集合（SID 0x10〜0x3E など）

ISO-TPにはフレームタイプがあります（後述します）。

要するに、CANは電気的な「通路」であり、そこを「輸送車」であるISO-TPが利用し、さらに「品物（ペイロード）」をUDSが担うイメージです。Ethernetの階層構造と同じような考え方で、上位層の内容を下位層は知りません。UDSの通信は、相手に正しく届いてからようやく、内容を読み解けるようになります。

ISO-TP のフレーム構造とアドレッシング

フレームタイプ

フレームタイプは次の4種類です。データ長は、データ長を示すデータそのものは含みません。

  • Single Frame (SF): 最大7バイト。1 パケットで完結
  • First Frame (FF): マルチフレームの1通目。全長を宣言
  • Consecutive Frame (CF): マルチフレームの2通目以降
  • Flow Control (FC): 受信側が送る「OK／待って／窒息しそう😫」を知らせるための信号

これにより、UDSという「品物」を分割してやりとりすることができます。

アドレッシング

アドレッシングには次の2通りの決め方があります。IDはECU毎に固有です。（この概念はCANの物理層の概念です）

  • 物理アドレッシング：1つのECUに対し1つのテスターで通信を行います。
  • 機能アドレッシング：全ECUへのブロードキャスト（一斉送信）です。

ID規則はOEMごとに細則がありますが、0x7E0/0x7E8 ペアは業界で半ば慣例化しています。

UDSの開始　ー Diagnostic Session Control（SID 0x10） ー

なぜ最初に DSC を叩くのか

UDSは、ECUの状態を切り替えます。ECUの状態を「サブファンクション」と呼びます。代表的なサブファンクションは次のとおりです。

サブファンクション名称主用途
0x01Default Session通常動作、アクセス最小
0x02Programming Sessionファーム更新許可
0x03Extended Diagnostic Session詳細診断、パラメータ変更
0x04Safety System Sessionエアバッグ系など安全関連

これらのサブファンクションによって、ECUが通信に対してどこまでを許すかが決まります。デフォルトは0x01のデフォルトセッションで、このままでは診断機能も限定的になるため、まず0x02のプログラミングセッションに切り替える必要があります。

そのため、UDSの開始時にはDSCを使ってECUの状態を変える通信が行われます。

CAN-ID : 0x7E0
Data   : 02 10 02 00 00 00 00 00
          ↑  ↑  ↑
          │  │  └ サブファンクション 0x02 = Programming
          │  └ SID 0x10 = DSC
          └ SF(ISO-TP), データ長2バイト

図は簡単な例です。CAN IDを頼りにISO-TPが届き、「荷物の中身」がDataの内容だった、というイメージです。図中の「SID」は「サービスID」です。これは「何をしたいのか」を伝えるためのIDなので「コマンド」のようなイメージで結構です。

DSCの応答には、P2やP2★（後述）が含まれることがあります。

セッション維持

ECUが、あるサブファンクションにある状態のときに行われる通信を「セッション」と呼びます。ECUは、ある一定期間、特定の「セッション維持のためのデータ」が来なかった場合は自動的にデフォルトセッションに戻ることになっています。

そのため、セッションを維持するためにはTesterPresent (0x3E) を 200–500 ms 間隔でECUに送り続けねばなりません。

UDSのセキュア

実際に診断やパラメータ変更などを行うためには、上述したDSCは「開始」に過ぎず、その後も手順に従って「第三者が読み取れない」情報をやりとりする必要があります。悪意ある第三者のアクセスを許すと、自動車は凶器に変わってしまう（などする）からです。

つまりUDS通信は暗号化されています。旧来も暗号化はされていましたが、UDS規格と比較すると脆弱なものです。こういった意味でも、新規格であるUDSへの移行は重要になっています。

旧式 Seed&Key 0x27新式 PKI 0x29
Seed を ECU→テスター送信X.509 証明書交換
テスターがKeyを算出し返送非対称署名で相互認証
アルゴリズムがバレると破られるチップセット連携のハードウェア Root-of-Trust

個々の用語に触れていると長くなりすぎるので、本記事では割愛します。

これらを踏まえた通信の手順は、大まかに次のようになります。

通信手順

  1. DSC で権限セッションへ
  2. Security Access でロック解除
  3. フラッシュやデータ書込み系サービスを実行

代表的サービスと応答規則

サービス（SID）に対し、応答は大きく分けて「OK」を示すPositive Response（PosRsp）と「NG」を示すNegative Response（NegRsp）があります。PosRspはSIDに対応しますが、NegRspはまず固定で0x7Fが返り、その後に要因を示すコードが返ってきます。

代表的なSIDを表にしてみました。

SIDPosRsp名称主用途
0x100x50DSCセッション切り替え
0x110x51ECU Resetソフト／ハードリセット
0x140x54Clear DTC故障コード消去
0x190x59Read DTCDTC 列挙
0x220x62ReadDataByIDDID 読取り
0x270x67Security AccessSeed & Key認証
0x290x69Authentication2020 追加の PKI 認証
0x2E0x6EWriteDataByIDDID 書込み
0x310x71Routine ControlCRC 計算, Erase Flash 等
0x340x74Request Downloadファーム転送
0x360x76Transfer Dataデータブロック送信
0x3E0x7ETester Presentセッション延命 Ping

本記事ではそれぞれを深堀りまではしませんが、「こういった機能がある」ということは押さえておきましょう。

VIN（Vehicle Identification Number）を読んでみる

VINは車両固有の識別子で、同じ識別子を持つ他の車両は存在しません。この識別子にはメーカーや車種を識別する内容も含まれ、各種診断をする前にまずVINを読み、必要な情報がどこにあるのかを区別するのが一般的です。

セキュアを確保するやりとりは複雑になるので、それを省いてVINを取得する手順を見てみましょう。

step.1 DSCでExtended Sessionに切替

02 10 03 … を送信　⇨　 50 03 … が返信され、ECUがExtended Sessionに切り替わる

step.2 DID読み取りを使ってVINを指定する

DIDはデータIDのことで、「DID読み取り」は指定されたIDのデータを読み取ることを意味します。これをECU（0x7E0）に送信します。

CAN-ID 0x7E0 : 03 22 F1 90 55 55 55 55
               ↑  ↑  ↑     ↑
               │  │  │     └ パディング
               │  │  └ DID = 0xF190 (VIN)
               │  └ SID 0x22
               └データ長3バイト (SF)

step.3 返信を解析する

送信時はシングルフレームSFを使っていますが、返信は8バイトを超えるためマルチフレーム（FF+CF）になっていることに注意してください。

CAN-ID 0x7E8 : 10 14 62 F1 90 57 50 30 …
               ↑  ↑  ↑  ↑　　　↑ ここからASCIIコードでVINデータ
               │  │  │  └ DID = 0xF190（VIN）
               │  │  └ PosRsp
               │  └ 全体バイト数（20バイト）
               └ マルチフレーム先頭の意味（FF）

               21 39 31 4B 33 52 58 30 …
               ↑  ↑ 
               │  └ VINデータの続き
               └ マルチフレームの2つめの返信の意味（CF）

step.4 VINを取り出す

最終的に受け取った返信からVINの部分をつなぎ合わせて、ASCIIコードで読むとWP0ZZZ99ZTS392124のようなVINが得られます。

タイムアウトの仕組み

通信を「これ以上待たない」というラインが2種類あります。この時間を超えて通信が途絶えてしまうと、タイムアウトと呼ばれるエラーになってしまいます。

P2とP2★

後者の「P2★」は「P2 Star」とも呼ばれ、前者と後者は違うものです。

用語どこで使う？何を測るタイミング？典型値
P2_Server_max
(一般に「P2」と呼称)		ECU（＝サーバ側）が持つリクエスト受信完了 → 最初の応答20～50 ms 程度
P2★_Server_max
(「P2★」または「P2 Star」)		ECU が持つ0x78 “ResponsePending” を返した後 → 最終応答1,000～ 5,000 ms 程度
P2_Client_max
/ P2★_Client_max		テスター（＝クライアント側）が持つ上記 ECU タイマに“通信遅延マージン”を乗せた待ち時間ECU 値 + α
目安：ECU 値 + 5 ms（P2）、+50 ms（P2★）

まとめると、

  1. P2 以内に ECU が応答できなければ、
  2. 0x78 “ResponsePending” を返して「待って」と告知
  3. その後 P2★ 以内に本応答を必ず出す。

というような流れになり、もし P2★ を超えれば 0x7F 10（General Reject） などの否定応答に切り替えるか、通信そのものをリセットするという動作になることがあります（ECU依存で、無応答のこともあります）。

P2だけでは処理速度的に厳しい場合の救済がP2★というイメージです。救済があるとはいえ、P2★のタイムアウトの挙動はECU依存なので、0x78が何度も返ってくるようであれば200msごとに0x3E（Tester Present）を送信すれば安全です。

これがUDSの「タイマー健全性」になります。

トラブルシューティング

ハマりがちなポイントと、対策の例を示します。

症状まず疑うポイント対策
0x7F 11SID間違いサービス表と照合
0x7F 78 無限ループECU内処理が長い200 ms 待って再ポーリング or TesterPresent
受信タイムアウトP2★が長いECU が返すP2★値をコードに反映
CF 取りこぼしSTmin/BlockSize 無視FC を解析して送信ペースを合わせる
セッション落ちTesterPresent 送信忘れ100–300 ms 周期で送信

まとめ

  • UDS は「SID」と「セッション」で構造化されており、流れを追えばシンプル。
  • DSC (0x10) → Security (0x27/0x29) → 各種サービス、という順序を体に叩き込む。
  • Pythonツールチェーンを使えば、自宅のテーブル上でも ECU 診断フローを再現できる。
  • 今後は DoIP (Diagnostics over IP) や AUTOSAR Adaptive といった Ethernet／POSIX ベースの新潮流が車載診断をアップデートしていく。

CANという規格自体が見直されつつあります。今後の動向には注意が必要でしょう。

  • B!