ISO15765-2（ISO-TP）を理解しよう
ISO15765とは？
ISO15765は、「Diagnostic communication over Controller Area Network (DoCAN)」（コントローラエリアネットワーク（DoCAN）を介した診断通信）というタイトルで、自動車の診断システムがCANバスを介して通信する際の要件やプロトコルについて規定している規格です。
ISO15765はPart1からPart5までの各Partに分かれており、各Partごとに診断通信の異なる側面やプロトコルに焦点を当てています。
| Part | Sub Title | 概要 |
|---|---|---|
| 1 | General information and use case definition | ネットワーク層プロトコルに関する要件 データフレームの構造や転送手順、メッセージIDの割り当て方法など |
| 2 | Transport protocol and network layer services | トランスポート層とネットワーク層のプロトコルに関する要件 診断データのセッション制御、メッセージのフロー制御、エラーチェック機構など |
| 3 | Implementation of unified diagnostic services (UDS on CAN) | 診断メッセージのフォーマットに関する要件 診断データの識別子、サイズ、パラメータの符号化、データの意味など |
| 4 | Requirements for emissions-related systems | ネットワーク管理に関する要件 ネットワークの初期化、ノードの識別、エラーハンドリング、通信速度の管理など |
| 5 | Specification for an in-vehicle network connected to the diagnostic link connector | データリンク層の要件 データフレームの送信と受信、エラーチェック機構、エラーリカバリなど |
ISO15765-2の概要
今回は前述のISO15765の中でも、Part2にあたるISO15765-2について取り上げます。
ISO15765-2では、トランスポート層とネットワーク層における車両の診断通信に必要なプロトコルとサービスの仕様が定義されており、ISO-TPとして一般に広く知られております。。
ネットワーク層では、メッセージを交換するためのアドレス情報を提供し、フレームの受信側と送信側を決定します。
トランスポート層では、主にフレームの分割に焦点を当てたデータフレームのフォーマット、メッセージの転送手順、エラーチェック機構、セッション制御などに関する仕様が規定されています。
この規格は、自動車業界における診断ツールや診断システムの開発において重要な役割を果たしています。
このようなCANを利用した診断通信の標準化により、異なる自動車メーカー間での互換性が向上し、診断作業の効率化やトラブルシューティングの容易化が実現されています。
CANフレーム
ISO15765-2の説明をする前に、CANフレームについて必要な部分のみ簡単に説明します
その他詳細については以下など参考にしてください。
CANフレーム
車両内の機器間における通信や、診断機と呼ばれる車両の状態を確認するためのツールを車両に接続して行う通信は、主にCAN (Controller Area Network)と呼ばれるシリアル通信プロトコルで実現しています。
CAN通信の中でやり取りされるCANフレームは、フレームの宛先を示すID、渡すデータのサイズを示すDLC（データレングスコード）、そしてデータ、最後に物理層、データリンク層におけるCAN通信制御に必要な各種情報で構成されています。
Classic CANとCAN FD
CANにはClassic CANとCAN FDという二種類の通信方式があります。
Classic CANは扱えるデータが最大8byteで最大1 Mbpsなのに対し、CAN FDは扱えるデータが最大64byteで最大5 Mbps以上の高速データ転送が可能です。
もともとはClassic CANのみだったのですが、時代とともに車両の高機能化が進み、扱うデータ量の増加に伴いCAN FDが開発されました。
CAN FDが使われるようになったことによって、ISO15765-2もCAN FDに対応するための規格内容の見直しが行われています。
標準フォーマットと拡張フォーマット
前述のClassic CANとCAN FDに加えて、CANフレームには標準と拡張の二種類のフォーマットが存在します。
それぞれCANフレームの宛先を示すIDのサイズが標準は11bit、拡張は29bitという違いがあります。
標準と拡張で前述のCANフレームの構造自体も少し変わってくるのですが、今回の規格においてはあまり重要でないため割愛します。
フォーマット一覧
併せて以下4パターンのCANフレームフォーマットが存在します。
| フォーマット | フレーム | IDサイズ |
|---|---|---|
| CAN標準フォーマット | Classic CAN | 11bit |
| CAN FD標準フォーマット | CAN FD | 11bit |
| CAN拡張フォーマット | Classic CAN | 29bit |
| CAN FD拡張フォーマット | CAN FD | 29bit |
DLC（データレングスコード）とデータ長
DLCで指定できる値とサイズの対応は以下のようになっています。
必ずしもDLCの値とデータ長が同じ値とはならないことに注意が必要です。
| DLC | Classic CAN データ長 | CAN FD データ長 |
|---|---|---|
| 0 | 0 | 0 |
| 1 | 1 | 1 |
| 2 | 2 | 2 |
| 3 | 3 | 3 |
| 4 | 4 | 4 |
| 5 | 5 | 5 |
| 6 | 6 | 6 |
| 7 | 7 | 7 |
| 8 | 8 | 8 |
| 9 | 8 | 12 |
| 10 | 8 | 16 |
| 11 | 8 | 20 |
| 12 | 8 | 24 |
| 13 | 8 | 32 |
| 14 | 8 | 48 |
| 15 | 8 | 64 |
CANフレームとISO15765-2
前述の通り、CANフレームが扱えるデータの最大長は最大64byteです。
一方で往々にして64byteを越えるようなデータを車両の通信では扱う必要があります。
こんな時は渡したいデータをフレーム単位に分割して相手に送信する必要が出てきます。
（例：160byteのデータを渡したいときは、40byteずつに分けて4っつのフレームを送信）
ISO15765-2が提供するのは主にこのデータを分割する仕組み、あるいは分割されたデータを組み立てる仕組みです。
ISO15765-2におけるネットワークレイヤ
前述の通り、ISO15765-2ではネットワーク層とトランスポート層における通信プロトコルを規定しております。
まずはISO15765-2におけるネットワークレイヤの規定について紹介します。
サービスプリミティブ
サービスプリミティブはOSI基本参照モデルなどにおける一般的な用語ですが、あまり耳慣れない言葉だったので簡単に整理しておきます。
サービスプリミティブ（Service Primitive）は、通信プロトコルにおいて上位層と下位層の間でデータのやり取りや制御情報の送受信を行うための基本的な操作やメッセージの形式を表す概念です。
一般的なサービスプリミティブには以下の4つのタイプがあります。
| タイプ | 方向 | 説明 |
|---|---|---|
| Request（要求） | 上位層 → 下位層 | 上位層から下位層への操作やデータの送信を要求するメッセージ 上位層が下位層に対してデータの送信や接続の確立などの操作を要求する際に使用する |
| Indication（指示） | 下位層 → 上位層 | 下位層から上位層への操作やイベントの通知を行うメッセージ 下位層が上位層に対してデータの受信やエラーの通知などを行う際に使用する |
| Response（応答） | 下位層 → 上位層 | 下位層から上位層への要求に対する応答メッセージ 下位層が上位層の要求に対して処理の結果や情報を返す際に使用 |
| Confirmation（確認） | 上位層 → 下位層 | 上位層から下位層への要求に対する確認メッセージ 上位層が下位層の要求に対して処理の完了や成功を通知する際に使用 |
下位と上位はそれぞれサービスプロバイダとサービスユーザとしての役割を担い四つのタイプと合わせて以下のような関係となります。
ただし、ISO15765-2のネットワークレイヤではResponceは定義していないため注意が必要です。
サービスプリミティブの詳細についてはISO15765-2の規格とは別に、以下の理解が必須となるためご確認願います。
https://uninformative.net/osi-reference-model/ネットワーク層サービスパラメータ
ISO15765-2においてネットワークレイヤが提供するサービスプリミティブで扱うパラメータには以下が存在します。
| パラメータ | 概要 | 型 | 設定値 | 説明 |
|---|---|---|---|---|
| Mtype | メッセージタイプ | 列挙型 | 診断 リモート診断 | 情報パラメータのタイプと範囲を決定するために使用 診断：N_AIにパラメータ N_SA、N_TA、および N_TAtype が含まれる リモート診断：N_AIにパラメータ N_SA、N_TA、N_TAtype、および N_AEが含まれる |
| N_AI | ネットワークアドレス情報 | ー | ー | アドレス情報全般 （N_SA、N_TA、N_TAtype、N_AE） |
| N_SA | ネットワーク送信元アドレス | 1 バイト符号なし整数 | 0x00 ～ 0xFF | 送信側ネットワーク層エンティティを表す |
| N_TA | ネットワーク宛先アドレス | 1 バイト符号なし整数 | 0x00 ～ 0xFF | 受信側ネットワーク層エンティティを表す |
| N_TAtype | ネットワークターゲットアドレスタイプ | 列挙型 | 下記参照 | N_TA パラメータの拡張 ネットワーク層の通信種別を表すために使用 |
| N_AE | ネットワークアドレス拡張 | 1 バイト符号なし整数 | 0x00 ～ 0xFF | 大規模なネットワークで通信を行う際、アドレスを拡張するために使用 |
| Length | データサイズ | 32 ビット | 0x00000000 ～ 0xFFFFFFFF | 送信または受信されるデータの長さ |
| MessageData | メッセージデータ | 文字列 | 任意 | 上位エンティティとのすべての対話データ |
| Parameter | パラメータ種別 | 列挙型 | STmin BS | 以下<Parameter_Value>を定義する |
| Parameter_Value | パラメータ値 | 1 バイト符号なし整数 | 0x00 ～ 0xFF | <Parameter>にて指定された定義に関する設定値 |
| N_Result | サービス実行結果 | 列挙型 | 下記参照 | サービスの実施結果 詳細については下記参照 |
| Result_ChangeParameter | サービス実行結果 | 列挙型 | 下記参照 | サービスの実施結果 詳細については下記参照 |
N_TAtype
N_TAtypeは通信内容に応じて指定する必要があります。
| # | 物理/機能 アドレス | Classic CAN/ CANFD | 標準/拡張 フォーマット |
|---|---|---|---|
| 1 | 物理アドレス（1対1通信における宛先指定） | Classic CAN | 標準 |
| 2 | 機能アドレス（1対多通信における宛先指定） | Classic CAN | 標準 |
| 3 | 物理アドレス（1対1通信における宛先指定） | CANFD | 標準 |
| 4 | 機能アドレス（1対多通信における宛先指定） | CANFD | 標準 |
| 5 | 物理アドレス（1対1通信における宛先指定） | Classic CAN | 拡張 |
| 6 | 機能アドレス（1対多通信における宛先指定） | Classic CAN | 拡張 |
| 7 | 物理アドレス（1対1通信における宛先指定） | CANFD | 拡張 |
| 8 | 機能アドレス（1対多通信における宛先指定） | CANFD | 拡張 |
N_Result
N_Resultには以下のようなエラー種別が存在します。
| N_Result | 説明 | 対象 |
|---|---|---|
| N_OK | サービスの実行が正常に完了した | 送信側/受信側 |
| N_TIMEOUT_A | タイマN_Ar/N_Asのタイムアウトを検知 | 送信側/受信側 |
| N_TIMEOUT_Bs | タイマN_Bsのタイムアウトを検知 | 送信側 |
| N_TIMEOUT_Cr | タイマN_Crのタイムアウトを検知 | 受信側 |
| N_WROMG_SN | 予期せぬシーケンスナンバー（SN）を受信 | 受信側 |
| N_INVALID_FS | 無効、または不明なフロウステータス（FS）が発生 | 送信側 |
| N_UNEXP_PDU | 予期せぬプロトコルデータユニット（PDU）を受信 | 受信側 |
| N_WFT_OVRN | N_WFTにおける性能要件未達（詳細については後述） | 受信側 |
| N_BUFFER_OVFLW | FS=OVFLWのN_PDUを受信 | 送信側 |
| N_ERROR | その他異常 | 送信側/受信側 |
Result_ChangeParameter
Result_ChangeParameterには以下のようなエラー種別が存在します。
| Result_ChangeParameter | 説明 | 対象 |
|---|---|---|
| N_OK | サービスの実行が正常に完了した | 送信側/受信側 |
| N_RX_ON | メッセージの受信が行われてからサービスが実行されなかった | 受信側 |
| n_wrong_parameter | 未定義のparameterによりサービスが実行されなかった | 送信側/受信側 |
| N_WRONG_VALUE | サービス利用者がサービス利用を中止した | 送信側/受信側 |
ネットワーク層サービスプリミティブ
最後にネットワーク層が提供するサービスプリミティブについてです。
サービスプリミティブごとに、前述のパラメータのうちどれを使用するかが変わってきます。
| サービスプリミティブ | 説明 | パラメータ |
|---|---|---|
| N_USData.request | 上位層がネットワーク層に対して＜Length＞byteの ＜MessageData＞送信を要求する | Mtype N_SA N_TA N_TAType [N_AE]（任意） <Length> <MessageData> |
| N_USData.confirm | ネットワーク層が上位層に対し、N_USData.requestサービスの 完了を通知するために発行する | Mtype N_SA N_TA N_TAType [N_AE]（任意） <N_Result> |
| N_USData_FF.indication | ネットワーク層が上位層に対し、ファーストフレーム（FF）受信を 通知するために発行する | Mtype N_SA N_TA N_TAType [N_AE]（任意） <Length> |
| N_USData.indication | ネットワーク層が上位層に対し、シングルフレーム（FF）の受信、または セグメントメッセージの受信完了あるいは失敗を通知するために発行する | Mtype N_SA N_TA N_TAType [N_AE]（任意） <MessageData> <Length> <N_Result> |
| N_ChangeParameter.request | 上位層がネットワーク層に対して<Parameter>で定義されている値に 対する<Parameter_Value>への変更を要求する FF（N_USData_FF.indication）受信後対応するメッセージの受信完了前を 除き常に本要求によるパラメータ変更は可能でなければならない。 | Mtype N_SA N_TA N_TAType [N_AE]（任意） <Parameter> <Parameter_Value> |
| N_ChangeParameter.confirm | ネットワーク層が上位層に対し、N_ChangeParameter.requestの サービスが完了したことを示すために発行する | Mtype N_SA N_TA N_TAType [N_AE]（任意） <Parameter> <Result_ChangeParameter> |
ISO15765-2におけるトランスポートレイヤ
ISO15765-2といえばここからがメインです。
トランスポート層では、通信データの構築、送受信の完了報告の役割を担います。
プロトコルデータユニット
トランスポート層における異なるECU間でのやり取りは、N_PDUを交換することで行われます。
N_PDU（Network Protocol Data Unit）は、ネットワークレイヤで扱うデータの単位であり、トランスポート層でこのデータの作成や確認を行います。
N_PDUの構成は以下の通りです。
| パラメータ | 説明 |
|---|---|
| N_AI | アドレス情報全般 （N_SA、N_TA、N_TAtype、N_AE） |
| N_PCI（Network Protocol Control Information） | N_PDUの制御情報を示す部分であり、N_PDUのタイプやサイズなどを定義する。 |
| N_DATA（Payload） | N_PDUの実際のデータ部分であり、トランスポート層で処理されるデータを含む。 |
プロトコルデータユニットタイプ
N_PDUには以下4つの通信用途に応じたデータ種別が存在します。
N_PDUがどのデータ種別かは、N_PCIから判断します。
| N_PDUType | 送信者 | 説明 |
|---|---|---|
| SF (Sinfge Frame) | 送信側 | 単一（1フレーム）で完結する情報を送信する際のフレーム |
| FF (First Frame) | 送信側 | 単一（1フレーム）で完結しない情報を送信する際の、最初のフレーム |
| CF (Consective Frame) | 送信側 | 単一（1フレーム）で完結しない情報を送信する際の、後続のフレーム |
| FC (Flow Control) | 受信側 | 単一（1フレーム）で完結しない情報を受信した際の、 後続のフレームのやり取りに対する調停のために、受信側が送信するフレーム |
FF、CF、FC、はいずれもマルチフレーム（単一フレームで完結しない、分割したデータを送信する）で使用するフレームです。
以下はマルチフレームの通信例です。
宛先の種別であるN_TAtypeにて物理アドレスと機能アドレスというものがありました。
物理アドレスが1対1通信を前提とするユニキャスト相当の宛先指定であるのに対し、機能アドレスが1対多通信を前提とするブロードキャスト、またはマルチキャスト相当の宛先指定となります。
物理アドレスにおいては、シングルフレーム(SF)、マルチフレーム(FF、CF、FC)いずれも使用可能ですが、機能アドレスにおいては通信シーケンスを持たないシングルフレーム(SF)しか扱えません。
N_PCIとN_DATA
N_PCIとN_DATAの構成は、前述のプロトコルデータユニットタイプによって変わります。
前提としてN_PCIとN_DATAは合わせてCANフレームのデータフィールドに格納されます。
CAN_DLはCANフレームのデータフィールドにおけるバイト数を示します。
Classick CANの場合は最大8byte、CANFDの場合は最大64byteのデータフィールドの中へ、N_PCIとN_DATAを納める必要があります。
N_PCIパラメータ
N_PCIで設定するパラメータは以下の通り。
| パラメータ | 名称 | 説明 |
|---|---|---|
| SF_DL | SingleFrame data length in bytes | シングルフレームの実データ長（byte単位） |
| FF_DL | FirstFrame data length in bytes | マルチフレームの実データ長（byte単位） データ長が4095以下の場合と4095より大きい場合で、 FFのフォーマット、ないしFF_DLのデータ長が変わる |
| SN | SequenceNumber | CF受信における、正しいデータの組み立て順序を確認するための値 FFフレームにおいてSNは含まれないが、暗黙的にFFのSNは0として扱う そのため、FF直後のCFのSN値は1となる 以降CF送信ごとに1ずつインクリメントしたSN値を設定する SNが15（0xF）になった場合、次CFフレームのSNは0へとラップアラウンドさせる |
| FS | FlowStatus | 受信側が自身のステータスを送信者へ通知するために使用する 0x0：CTS（Continue To Send） 最大BS個のフレーム受け入れ準備が出来ている 0x1：WAIT フレームの受け入れ準備が出来ていない 0x2：OVFLW（OverFlow） FFにて指定されたFF_DLが受信側のバッファに収まらない 上記以外：Reserved |
| BS | BlockSize | 受信側が連続して受信可能なフレーム数を指定するために使用する 0x00：FCを待たずすべてのフレーム送信を行うことを要求 0x01~0xFF：指定値のフレーム数送信後はFCを待つことを要求 |
| STmin | Separation Time Minimum | 受信側が送信側に対し、CFを連続して送信する際の送信間隔を指定する 0x00~0x7F：指定時間（msec）送信間隔をあけることを要求 0xF1~0xF9：指定時間（100μsec~900μsec）送信間隔をあけることを要求 上記以外：Reserved |
FCによるBS、STmin指定イメージ。
その他パラメータ
以降は通信ではやり取りしないが、システム設計として考慮が必要となるパラメータの説明となります。
タイミングパラメータ
送信側、受信側それぞれで通信状態に応じたタイマ管理を実施します。
| パラメータ | 検知 | 概要 | タイムアウト 時間(msec) | 性能要件 | タイムアウト検知動作 | エラー |
|---|---|---|---|---|---|---|
| N_As | 送信側 | データ送信が完了するまでの時間 (送信側：SF、FF、CF) | 1000 | – | メッセージの送信を中止 | N_TIMEOUT_A |
| N_Ar | 受信側 | データ送信が完了するまでの時間 (受信側：FC) | 1000 | – | メッセージの送信を中止 | N_TIMEOUT_A |
| N_Bs | 送信側 | データ送信完了から 次のFC受信までの時間 | 1000 | – | メッセージの送信を中止 | N_TIMEOUT_Bs |
| N_Br | 受信側 | データ受信完了から 次のFC送信までの時間 | N/A | N_Br + N_Ar < 0.9×N_Bs | – | – |
| N_Cs | 送信側 | データ送信完了から 次のCF送信までの時間 | N/A | N_Cs + N_As < 0.9×N_Cr | – | – |
| N_Cr | 受信側 | データ送信完了（FC）、または データ受信完了（CF）から 次のCF受信までの時間 | 1000 | – | メッセージの送信を中止 | N_TIMEOUT_Cr |
以下はタイムアウト検知間隔を図示したものです。
通信シーケンスを網羅的にタイムアウト検知できるようになっているため、仮に送信者がどこかのタイミングで通信不能となった場合も、タイムアウト検知によって受信者は通信を終了することが出来ます。
上記は受信者が通信不能となった場合の送信者にも当てはまります。
N_WFTmax（Number of Wait Frames Transmitter maximum）
N_WFTmax（Number of Wait Frames Transmitter maximum）は、受信側がFCのWAITパラメータを連続して送信可能な回数を表します。
というのも送信側がマルチフレーム送信したのち受信側からのFC WAITを受信した場合、以降はFC CTSを待ち続ける必要が出てきます。
上記の待ち時間のタイムアウト値として、N_Bsが定義されているのですが、再度FC WAITを受信することでこのタイマはまたクリアされます。
このFC WAITを繰り返し送信し続けることで、送信者の処理待ちが永遠に発生してしまうことを防ぐためにN_WFTmaxというパラメータ受信側にて管理しています。
ISO15765-2におけるアドレッシングフォーマット
ISO15765-2では、CANフレームのID配置について、以下4種類のアドレッシングフォーマットを規定しています。
（Mixed addressingについては標準/拡張フォーマットに応じて構成が異なるためさらに分けています）
| フォーマット | 対象 フォーマット | 概要 |
|---|---|---|
| Normal addressing | 標準/拡張 | CANIDとN_AIの各要素（N_TA、N_SA）の間に厳密な紐づけはない |
| Normal fixed addressing | 拡張 | CANIDとN_AIの各要素（N_TA、N_SA）の間に厳密な紐づけがある |
| Extended addressing | 標準/拡張 | CANIDとN_AIの各要素（N_TA、N_SA）の間に厳密な紐づけはない ただし、N_TAはCANフレームのDataFieldにおける1byte目に設定する |
| Mixed addressing（標準） | 標準 | Mtypeがリモート診断の時のみ対象 CANIDとN_AIの各要素（N_TA、N_SA）の間に厳密な紐づけはない また、N_AEはCANフレームのDataFieldにおける1byte目に設定する |
| Mixed addressing（拡張） | 拡張 | Mtypeがリモート診断の時のみ対象 CANIDとN_AIの各要素（N_TA、N_SA）の間に厳密な紐づけがある また、N_AEはCANフレームのDataFieldにおける1byte目に設定する |
システム設計によっていずれのフォーマットを採用するかは決められます。
Normal addressing
Normal fixed addressing
Extended addressing
Mixed addressing（標準）
Mixed addressing（拡張）
ISO15765-2におけるパディング
SFやマルチフレームの最後のCFにおいて、パディングが必要となることがあります。
フレームのDLCで指定したデータ長に対して、実データがそれよりも短い場合が該当します。
そんな時は「0xCC」で残りのデータバイトを埋めることがISO15765-2では規定されています。
もちろんフレームの実データ長と、DLCのサイズが一致している場合にはパディングは不要です。
以下はシングルフレームのパディング例です。
最後に
ISO 15765-2についてはまだ説明しきれていない部分があるのですが、重要な部分についてはだいたい取り上げられたかと思います。
pythonのライブラリでISO 15765-2の通信を動かせるらしいので、そのうち試してみようかと思います。
https://kakitamablog.com/python-can_isotp/