pythonでDoIP　~③DoIPプロトコル通信フォーマット概要~

2022年4月17日DoIP,DoIP,python

今回はDoIP通信プロトコルについて解説したいと思います。

TCP/UDPでDoIP通信を実施するために必要最低限の通信内容のみ取り上げているため、詳細については実際に規格（ISO13400）を確認してください。

前提条件

DoIPでは、診断機が直接DoIP通信を実施する対象としてGW（ゲートウェイ）が存在します。

また、ゲートウェイによるルーティング処理を介して車両内の様々なECU（エンジンコントロールユニット： engine control unit）との診断通信を想定しております。

ルーティングにおける通信プロトコルは任意（UDS、DoIP、そのほか独自プロトコル等）とされています。

今回このルーティング処理は対象外とし、診断機とゲートウェイ間のDoIP通信のみを想定した構成とます。

またDoIPサーバであるゲートウェイは、通信前にDHCPによってIPアドレスを取得し、取得したIPアドレスをマルチキャストで通知する必要があるのですが、ここら辺の動きも対象外とします。

ポート番号

サーバの待ち受けポート番号は13400を指定します。

規格番号（ISO13400）と使用するポート番号が同じというのは分かりやすいですね。

DoIPクライアントは、同時に複数のDoIPサーバと通信することを想定しているため、クライアント側のポート番号は動的に設定されます。

通信フォーマット

DoIPヘッダ構造

＊プロトコルバージョンについては0x02(DoIP ISO 13400-2：2012)を今回指定しています。

DoIPペイロードタイプの概要

DoIP通信におけるUDPメッセージ

主に以下役割を持っています。

DoIPサーバ（車両内ゲートウェイ）が自身の存在を、DoIPクライアント（診断機）へ通知する。

DoIPクライアント（診断機）が、DoIPサーバ（車両内ゲートウェイ）の存在またはDoIP通信状態を確認する。

UDPの役割としてはあくまでも事前確認のみとなり、実際のUDS相当の診断通信はTCPで実施します。

UDPコマンド

Generic DoIP header negative acknowledge

DoIPヘッダーで検出された特定のエラーを示すか、サポートされていないペイロードまたはメモリ過負荷状態を示す。

Vehicle identification request message

車両情報を要求する。

ペイロードなし。（ペイロード長＝0）

Vehicle identification request message with EID

EID（MACアドレス）とともに車両情報を要求する。

受信側（DoIPサーバ）は本メッセージペイロードのEIDと自身のEIDが一致した場合にのみvehicle identification response messageを応答する。

Vehicle identification request message with VIN

VIN（ISO 3779で指定されている車両の識別番号）とともに車両情報を要求する。

受信側（DoIPサーバ）は本メッセージペイロードのVINと自身のEIDが一致した場合にのみvehicle identification response messageを応答する。

Vehicle announcement message/vehicle identification response message

Vehicle announcement messageは、有効なIPアドレスの構成直後に自発的に車両情報をマルチキャストで提供する。

DoIPではDHCPによる動的なIPアドレスの取得が規定されているため、このようにDoIPサーバは自身のIPアドレスを教えてあげる必要があります。

vehicle identification response messageは、DoIPクライアントからの要求に応じて車両情報をユニキャストで応答する。

どちらもペイロード内容は同一となる。

アクションコードとVIN / GID同期状態の対応はオプション(対応してもしなくてもよい)ということなので今回はデフォルト値を設定します。

DoIP entity status request

該当機器のDoIP通信における通信対応ステータスを確認する。（同時接続可能なソケット数、現在確立中のソケット数等）

ペイロードなし。（ペイロード長＝0）

DoIP entity status response

DoIP entity status requestに対するレスポンス。

Diagnostic power mode information request

車両の診断を実行する準備が出来ているかを確認する。

ペイロードなし。（ペイロード長＝0）

Diagnostic power mode information response

Diagnostic power mode information requestに対するレスポンス。

DoIP通信におけるTCPメッセージ

DoIPにぉける車両診断情報のやり取りは、TCPコマンドを介して行われます。

また、事前にアクティベーションといって、TCPコネクション確立後、DoIPプロトコルにおける診断通信実施のための論理的なコネクションを確立させる必要があります。

アクティベーション成功後、DoIPコマンドのDiagnostic messageを介してUDSなどの診断メッセージのやり取りが可能となります。

Routing activation request

本要求でアクティベートが完了したのち、Diagnostic messageにて診断通信が開始できる。

Routing activation response

Routing activation requestに対するレスポンス。

Alive check request

該当TCPソケットのアクティベートが有効かかどうかを確認する。

ペイロードなし。（ペイロード長＝0）

Alive checkによる確認は、DoIPクライアント（診断機）→ DoIPサーバ（ゲートウェイ）だけでなく、下記両方で扱う。

DoIPクライアント（診断機）→ DoIPサーバ（ゲートウェイ）

DoIPサーバ（ゲートウェイ）→ DoIPクライアント（診断機）

Alive check response

Alive check requestに対するレスポンス。

有効なDoIPコネクションが存在する場合は自身のロジカルアドレスを応答する。

Diagnostic message

診断メッセージ。

本コマンドは下記両方で扱う。

DoIPクライアント（診断機）→ DoIPサーバ（ゲートウェイ）

DoIPサーバ（ゲートウェイ）→ DoIPクライアント（診断機）

Diagnostic message positive acknowledgement

Diagnostic messageに対するポジティブ応答。

Diagnostic message negative acknowledgement

Diagnostic messageに対するネガティブ応答。

最後に

DoIPプロトコルの解説はここまでとします。

タイムアウトなど、今回紹介しきれなかった要素は多々あるため気になる方は一度規格をご確認ください。

次回からはいよいよ本格的な実装に移ろうと思います。