CAN FDプロトコル

CAN FDプロトコルの紹介

CAN FD（Controller Area Network Flexible Data-Rate）は、電気機器や制御システムの異なる部品間の2線式相互接続において、センサーデータや制御情報をブロードキャストするために一般的に使用されるデータ通信プロトコルです。CAN FDは、オリジナルのCANバスプロトコルの拡張版です。CAN FDは、最新の自動車用電子制御ユニット（ECU）をはじめとする多くの産業用アプリケーションでの使用を想定し、データ転送速度の向上（CAN FDでは最大5倍の速度向上）と、より大きなメッセージフレームサイズのサポートというニーズに応えるために開発されました。

標準CAN（コントローラエリアネットワーク）とCAN FDの主な違いは、フレキシブルデータ（FD）です。CAN FDを使用することで、電子制御ユニット（ECU）は異なるデータレートに切り替え、より大きなメッセージサイズまたはより小さなメッセージサイズで通信できます。CAN FDの拡張機能には、より高速またはより低速のデータレートを選択して切り替える機能や、同じCANメッセージにより多くのデータを詰め込む機能などがあり、CANネットワーク経由での転送時間を節約します。データ速度の高速化とデータ容量の拡張により、標準CANと比較してシステム運用上のさまざまな利点が得られます。CAN FDを使用すると、センサーデータと制御データをECUソフトウェアでより高速に送受信できます。

メッセージには識別子（ID）が付けられます。識別子は11ビット（標準ID）または29ビット（拡張ID）で、ネットワーク上の1つ以上のノードに割り当てられます。すべてのノードはメッセージを受信し、フィルタリング操作を実行します。つまり、各ノードは識別子に基づいて受け入れテストを実行し、メッセージとその内容がそのノードに関連があるかどうかを判断します。メッセージが関連するノードのみがメッセージを処理します。それ以外のノードはメッセージを無視します。

識別子にはさらに2つの機能があります。メッセージの優先度を指定するデータが含まれており、ハードウェアがバスのアービトレーションを行う際に使用されます。つまり、複数のノードが同時に送信しようとした場合に、どのノードが送信するかを決定するために使用されます。メッセージIDは、単一のCAN FDネットワーク内で一意である必要があります。一意でない場合、2つのノードがアービトレーションフィールド（ID）の終端を超えて送信を継続し、エラーが発生します。数値IDが小さいほど、メッセージの優先度が高くなります。

CAN FDは、1つのCAN FDメッセージで最大64バイトのデータを送信できます。これは、CANバスとCAN FDの主な違いの一つです。DLCフィールド（データ長コード）は、データフィールドに含まれるデータのバイト数を示します。

Typhoon HILツールチェーンのCAN FDプロトコル

現在、Typhoon HIL の CAN FD 機能は、HIL デバイス（次の Typhoon HIL デバイスでサポートされています： HIL506 および HIL606 ）に直接実装されているか、ACE ボード（ Automotive Communication Extender ）を介して実装されています。

HIL506とHIL606には、それぞれ独立したCAN FDコントローラが搭載されています。これらの2つのコントローラは、標準の9ピンD-Subタイプ（オス）コネクタを介してCAN FDネットワークに接続できます。

各HILデバイスモデルで利用可能なポートに関する情報は、各デバイスのハードウェアマニュアルの「一般仕様」セクションに記載されています。各HILデバイスごとのCANコネクタのピン配置は、以下をご覧ください。

• HIL506 ピン配置
• HIL606 ピン配置

ACE ボード上の CAN FD コントローラのコネクタ ピン配列については、 「自動車用通信エクステンダ カードのピン配列」で説明します。

HIL デバイス上の CAN FD コントローラーは抵抗器で終端されていません。必要に応じて 120 オームの終端抵抗器を追加する必要があります。

ACE ボード上の CAN FD コントローラは 120 オームの抵抗で終端されています。

CAN FD コントローラが HIL デバイス上にあるか ACE ボード上にあるかに応じて、各 CAN FD コントローラは、 CAN FD セットアップコンポーネントまたはACE CAN セットアップコンポーネントを使用して構成できます。

各 CAN FD コントローラーは、メッセージの受信と送信に使用できます。CAN FD 送信コンポーネントとCAN FD 受信コンポーネントは、メッセージの送受信を定義するために使用されます。

CAN FDプロトコルでは64ビットデータの送受信がサポートされていますが、HILデバイス内のすべてのレジスタは32ビットです。つまり、受信データは32ビットに変換され、送信された64ビットデータは32ビットデータとしてパックされて送信されます。

また、リモート フレームの処理は現在サポートされていないことにも注意してください。

CAN FDセットアップ

CAN FDセットアップコンポーネントを図2に示します。これは、モデルで使用される各HILデバイスのCAN FDコントローラを設定するために使用されます。

CAN FD プロトコルを使用する場合、CAN FD プロトコルを使用する HIL デバイスごとに CAN FD セットアップ コンポーネントが 1 つだけ存在する必要があります。

CAN FD送信

CAN FD送信コンポーネントを図3に示します。これは、送信する単一のCAN FDメッセージの形式と値を指定するために使用されます。

複数のシグナルを単一のCAN FDメッセージで送信できます。+（プラス）ボタンをクリックすると、CAN FD送信ダイアログウィンドウのシグナルテーブルに新しいシグナルが追加されます。すべてのシグナルは、シグナルパラメータで定義された方法で1つのメッセージにまとめられます。メッセージのプレビューはテーブルの右側に表示されます。

図 4 は信号を定義する方法を示しています。

スタートビットの値は、フレームのデータフィールド内における信号の位置を指定します。バイトオーダーがリトルエンディアンの信号の場合は、最下位ビットの位置が示されます。バイトオーダーがビッグエンディアンの信号の場合は、最上位ビットの位置が示されます。ビットは鋸歯状にカウントされます。

係数とオフセットは、信号のコード化された値をその信号の物理値に変換したり、その逆を行ったりする線形変換を定義します。

coded_value = (physical_value - offset) / scale

物理値 = コード値 * スケール + オフセット

最小値と最大値は、信号の有効な物理値の範囲を定義します。

信号をリストに追加すると、CAN FD送信コンポーネントは図5のようになります。信号ポートは、モデルの任意の信号処理部分に接続できます。

回路図には多数のCAN FD送信コンポーネントが存在する可能性があり、各コンポーネントは送信するCAN FDメッセージを1つ記述します。複数のメッセージを送信するためにモデルにCAN FD送信コンポーネントを追加する場合は、すべてのメッセージに一意のIDが付与されていることを確認する必要があります。

CAN FD受信

CAN FD受信コンポーネントを図6に示します。これは、CAN FDネットワークを介して受信したメッセージを解凍するために使用されます。

+（プラス）ボタンをクリックすると、CAN FD受信ダイアログウィンドウの信号テーブルに新しい信号が追加されます。すべての信号は、信号パラメータで定義された方法で展開されます。

図 7 は信号を定義する方法を示しています。

スタートビットの値は、フレームのデータフィールド内における信号の位置を指定します。バイトオーダーがリトルエンディアンの信号の場合は、最下位ビットの位置が示されます。バイトオーダーがビッグエンディアンの信号の場合は、最上位ビットの位置が示されます。ビットは鋸歯状にカウントされます。

係数とオフセットは、信号のコード化された値をその信号の物理値に変換したり、その逆を行ったりする線形変換を定義します。

coded_value = (physical_value - offset) / scale

物理値 = コード値 * スケール + オフセット

最小値と最大値は、信号の有効な物理値の範囲を定義します。

信号をリストに追加すると、CAN FD受信コンポーネントは図8のようになります。信号ポートは、モデルの任意の信号処理部分に接続できます。

回路図には多数のCAN FD受信コンポーネントを配置することができ、各コンポーネントは定義されたID値を持つCAN FDメッセージの受信に使用されます。CAN FD受信コンポーネントで定義されたID値と一致しないID値を持つメッセージは無視されます。

新しいメッセージが受信されるたびに、rcv_cnt 値は 1 ずつ増加します。

RAMオーバーフロー防止とFIFOサイズ計算

RAMの2048バイトという制限のため、オーバーフローを防ぐためにFIFOバッファサイズを計算する必要があります。計算されたFIFOサイズは、単一のコントローラ上でデータ損失なしに同時にメッセージを送受信できるコンポーネントの数を制限します。送信と受信のFIFOサイズは、送信コンポーネントと受信コンポーネントの両方が同じコントローラ上で同時に使用されるか、どちらか一方だけ使用されるかに基づいて計算されます。

• 送信コンポーネントと受信コンポーネントは同じCAN FDコントローラを使用します。最大FIFOサイズを計算する式は、送信コンポーネントと受信コンポーネントの両方に適用されます。

  $f私fo\_s私ze\_\mathrm{メートル}\mathrm{1つの}\times =\frac{tot\mathrm{1つの}l\_r\mathrm{1つの}\mathrm{メートル}}{2(d\mathrm{1つの}t\mathrm{1つの}\_len\mathrm{グラム}th+\mathrm{メートル}et\mathrm{1つの}\_d\mathrm{1つの}t\mathrm{1つの}\_len\mathrm{グラム}th)}$

• 送信コンポーネントと受信コンポーネントのみが同一のCAN FDコントローラを使用します。最大FIFOサイズを計算する式は、送信コンポーネントと受信コンポーネントの両方に適用されます。

  $f私fo\_s私ze\_\mathrm{メートル}\mathrm{1つの}\times =\frac{tot\mathrm{1つの}l\_r\mathrm{1つの}\mathrm{メートル}}{d\mathrm{1つの}t\mathrm{1つの}\_len\mathrm{グラム}th+\mathrm{メートル}et\mathrm{1つの}\_d\mathrm{1つの}t\mathrm{1つの}\_len\mathrm{グラム}th}$

どちらの場合も、 fifo_size_maxが32を超えると、FIFOサイズの制限内に収まるように32に制限されます[ 1 ]。

数式パラメータ:

• total_ram : CAN FDコントローラで使用可能なRAMの量（つまり2048バイト）
• data_length : 単一コントローラで使用されるすべてのCAN送信/受信コンポーネントの最大データ長
• meta_data_length : ヘッダーや追加の制御情報など、各メッセージのメタデータの長さ（バイト単位）。デフォルト値は20バイトです。

設定ファイルを使用してCANメッセージを指定する

送信コンポーネントと受信コンポーネントはどちらも、DBCファイルまたはARXMLファイルをインポートしてメッセージを定義できます。基本的な動作はどちらのコンポーネントでも同じですが、ここではCANバス送信コンポーネントについてのみ説明します。

設定ファイルを読み込むには、「データ入力」プロパティで「設定ファイル」を選択し、 「ファイルの選択」ボタンを使用して目的のファイルを選択します。ファイルが正しく解析されていれば、 「メッセージの選択」コンボボックスにファイル内のメッセージ名が表示されます。異なるメッセージを選択すると、ダイアログ内のメッセージとシグナルのパラメータが変更されます。例を図9に示します。

DBCファイルまたはARXMLファイルを使用してCANメッセージを定義する場合、すべてのメッセージおよび信号パラメータは編集不可となります。データ入力をダイアログウィンドウに変更するとパラメータは編集可能になりますが、その後データ入力を構成ファイルに戻すと、パラメータは構成ファイルの値に戻ります。

Schematic API を使用してコンポーネントのプロパティ値を変更する

カスタムコンポーネントダイアログは、CANメッセージのパラメータを簡単に定義できるように設計されています。これらの値の変更は、標準の回路図API関数を使用しても可能ですが、変更された方法となります。つまり、送信メッセージと信号情報を除くすべてのプロパティは標準的な方法で変更されます。送信メッセージはPython辞書型として指定し、要求情報はPython辞書型のリストとして指定する必要があります。

transmit_type = {
    "On event": True,
    "On timer": False
}
mdl.set_property_value(mdl.prop(can_component, "transmit_type"), transmit_type)

signals = [
    {"name": "signal0", "start_bit": 0, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "None"},
    {"name": "signal1", "start_bit": 8, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxer"},
    {"name": "signal2", "start_bit": 16, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxed", "mux_val": "0"},
    {"name": "signal3", "start_bit": 16, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxed", "mux_val": "1"}
]
mdl.set_property_value(mdl.prop(can_component, "signals"), signals)

dbc_file_path = r"C\dbc_files\ford_fusion_2018_pt.dbc" mdl.set_property_value(mdl.prop(can_component, "file_path"), dbc_file_path) mdl.set_property_value(mdl.prop(can_component, "choose_message"), "Lane_Keep_Assist_Control")

CAN実行レートの説明

このセクションでは、これらのそれぞれの値と、それらの相互関係を明確にすることを目的としています。

まず、CAN通信プロトコルを使用するすべてのモデルにおいて、2つの側面を区別することが重要です。信号処理の側面と、CAN通信プロトコル自体の処理です。モデルのコンパイル時に、回路図上のすべての信号処理コンポーネントは、1つのCPUコアで実行される1つのアプリケーションに統合されます。一方、すべてのCANコンポーネント（信号処理ライブラリの一部であっても）は、別のCPUコアで実行される別のアプリケーションに統合されます。これら2つのアプリケーションは、それぞれ異なるエンティティです。

すべての信号処理コンポーネント（CANコンポーネントを含む）には実行レートプロパティがあります。接続され、論理関数を実行するすべてのコンポーネントは、同じ実行レート値を共有します。実行レート値は、その関数が実行される頻度を定義します。

CANxコントローラの実行レートはCANアプリケーションに固有の機能を持ちますが、CAN関数が呼び出される頻度を定義します。

各CAN送信コンポーネントには、メッセージがネットワークに送信される頻度を定義する送信周期プロパティがあります。送信周期とCANxコントローラの実行速度は直接相関しており、 CANxコントローラの実行速度は送信周期の粒度値として機能します。つまり、 CANxコントローラの実行速度が1msに設定されている場合、送信周期は1msの整数倍、つまりN*1msのみとなります。同様に、 CANxコントローラの実行速度が3msに設定されている場合、送信周期はN*3msのみとなります。

ボーレートは、CAN規格で定義されている唯一の値です。この値はビット/秒で表され、2つのCANコントローラ間でメッセージが中継される速度を定義します。送信周期とボーレートの違いは、メトロノームの例で簡単に説明できます。メトロノームは定期的にクリック音を発しますが（送信周期）、そのクリック音は音速でリスナーに伝わります（ボーレート）。

図 10 は上で説明した内容をすべて示しています。

仮想HILサポート

Virtual HILは現在このプロトコルをサポートしていません。非リアルタイム環境（例：ローカルコンピュータでモデルを実行する場合）を使用する場合、このコンポーネントへの入力は破棄され、このコンポーネントからの出力はゼロになります。

参考文献

1. Microchip Technology Inc.、「MCP251XXFD CAN-FDコントローラモジュールファミリリファレンスマニュアル」、2017-2018、22ページ