. ISO15765-2（ISO-TP）を理解しよう
ISO15765-2（ISO-TP）を理解しよう
ISO15765-2（ISO-TP）を理解しよう

ISO15765-2（ISO-TP）を理解しよう

2023年7月1日ISO15765,勉強

Contents
  • 1. ISO15765とは？
    • 1.1. ISO15765-2の概要
  • 2. CANフレーム
    • 2.1. CANフレーム
    • 2.2. Classic CANとCAN FD
    • 2.3. 標準フォーマットと拡張フォーマット
    • 2.4. フォーマット一覧
    • 2.5. DLC（データレングスコード）とデータ長
    • 2.6. CANフレームとISO15765-2
  • 3. ISO15765-2におけるネットワークレイヤ
    • 3.1. サービスプリミティブ
    • 3.2. ネットワーク層サービスパラメータ
      • 3.2.1. N_TAtype
      • 3.2.2. N_Result
      • 3.2.3. Result_ChangeParameter
    • 3.3. ネットワーク層サービスプリミティブ
  • 4. ISO15765-2におけるトランスポートレイヤ
    • 4.1. プロトコルデータユニット
      • 4.1.1. プロトコルデータユニットタイプ
      • 4.1.2. N_PCIとN_DATA
      • 4.1.3. N_PCIパラメータ
    • 4.2. その他パラメータ
    • 4.3. タイミングパラメータ
      • 4.3.1. N_WFTmax（Number of Wait Frames Transmitter maximum）
  • 5. ISO15765-2におけるアドレッシングフォーマット
    • 5.1. Normal addressing
    • 5.2. Normal fixed addressing
    • 5.3. Extended addressing
    • 5.4. Mixed addressing（標準）
    • 5.5. Mixed addressing（拡張）
  • 6. ISO15765-2におけるパディング
  • 7. 最後に

ISO15765とは？

ISO15765は、「Diagnostic communication over Controller Area Network (DoCAN)」（コントローラエリアネットワーク（DoCAN）を介した診断通信）というタイトルで、自動車の診断システムがCANバスを介して通信する際の要件やプロトコルについて規定している規格です。

ISO15765はPart1からPart5までの各Partに分かれており、各Partごとに診断通信の異なる側面やプロトコルに焦点を当てています。

PartSub Title概要1General information and use case definitionネットワーク層プロトコルに関する要件データフレームの構造や転送手順、メッセージIDの割り当て方法など2Transport protocol and network layer servicesトランスポート層とネットワーク層のプロトコルに関する要件診断データのセッション制御、メッセージのフロー制御、エラーチェック機構など3Implementation of unified diagnostic services (UDS on CAN)診断メッセージのフォーマットに関する要件診断データの識別子、サイズ、パラメータの符号化、データの意味など4Requirements for emissions-related systemsネットワーク管理に関する要件ネットワークの初期化、ノードの識別、エラーハンドリング、通信速度の管理など5Specification 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 FD

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 CAN11bitCAN FD標準フォーマットCAN FD11bitCAN拡張フォーマットClassic CAN29bitCAN FD拡張フォーマットCAN FD29bit DLC（データレングスコード）とデータ長

DLCで指定できる値とサイズの対応は以下のようになっています。

必ずしもDLCの値とデータ長が同じ値とはならないことに注意が必要です。

DLCClassic CANデータ長CAN FDデータ長0001112223334445556667778889812108161182012824138321484815864 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の規格とは別に、以下の理解が必須となるためご確認願います。

Unknown Title

uninformative OSI参照モデル ここではコンピュータ通信を行うプロトコルの共通の基盤となる概念である ...

 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パラメータ種別列挙型STminBS以下<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_OVRNN_WFTにおける性能要件未達（詳細については後述）受信側N_BUFFER_OVFLWFS=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＞送信を要求するMtypeN_SAN_TAN_TAType[N_AE]（任意）<Length><MessageData>N_USData.confirmネットワーク層が上位層に対し、N_USData.requestサービスの完了を通知するために発行するMtypeN_SAN_TAN_TAType[N_AE]（任意）<N_Result>N_USData_FF.indicationネットワーク層が上位層に対し、ファーストフレーム（FF）受信を通知するために発行するMtypeN_SAN_TAN_TAType[N_AE]（任意）<Length>N_USData.indicationネットワーク層が上位層に対し、シングルフレーム（FF）の受信、またはセグメントメッセージの受信完了あるいは失敗を通知するために発行するMtypeN_SAN_TAN_TAType[N_AE]（任意）<MessageData><Length><N_Result>N_ChangeParameter.request上位層がネットワーク層に対して<Parameter>で定義されている値に対する<Parameter_Value>への変更を要求するFF（N_USData_FF.indication）受信後対応するメッセージの受信完了前を除き常に本要求によるパラメータ変更は可能でなければならない。MtypeN_SAN_TAN_TAType[N_AE]（任意）<Parameter><Parameter_Value>N_ChangeParameter.confirmネットワーク層が上位層に対し、N_ChangeParameter.requestのサービスが完了したことを示すために発行するMtypeN_SAN_TAN_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_DLSingleFrame data length in bytesシングルフレームの実データ長（byte単位）FF_DLFirstFrame data length in bytesマルチフレームの実データ長（byte単位）データ長が4095以下の場合と4095より大きい場合で、FFのフォーマット、ないしFF_DLのデータ長が変わるSNSequenceNumberCF受信における、正しいデータの組み立て順序を確認するための値FFフレームにおいてSNは含まれないが、暗黙的にFFのSNは0として扱うそのため、FF直後のCFのSN値は1となる以降CF送信ごとに1ずつインクリメントしたSN値を設定するSNが15（0xF）になった場合、次CFフレームのSNは0へとラップアラウンドさせるFSFlowStatus受信側が自身のステータスを送信者へ通知するために使用する0x0：CTS（Continue To Send） 最大BS個のフレーム受け入れ準備が出来ている0x1：WAIT フレームの受け入れ準備が出来ていない0x2：OVFLW（OverFlow） FFにて指定されたFF_DLが受信側のバッファに収まらない上記以外：ReservedBSBlockSize受信側が連続して受信可能なフレーム数を指定するために使用する0x00：FCを待たずすべてのフレーム送信を行うことを要求0x01~0xFF：指定値のフレーム数送信後はFCを待つことを要求STminSeparation 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_AN_Ar受信側データ送信が完了するまでの時間(受信側：FC)1000–メッセージの送信を中止N_TIMEOUT_AN_Bs送信側データ送信完了から次のFC受信までの時間1000–メッセージの送信を中止N_TIMEOUT_BsN_Br受信側データ受信完了から次のFC送信までの時間N/AN_Br + N_Ar<0.9×N_Bs––N_Cs送信側データ送信完了から次のCF送信までの時間N/AN_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の通信を動かせるらしいので、そのうち試してみようかと思います。

【python-can】ISO-TPの勉強！シミュレーションで動作確認するぞ！！ | かきエレ

みなさま、お疲れ様です。今回はpythonを使ってISO-TPのシミュレーションをしてみようと思います。ISO- ...

 https://kakitamablog.com/python-can_isotp/

2023年7月1日ISO15765,勉強ISO-TP,ISO15765

📎📎📎📎📎📎📎📎📎📎