CANバスプロトコル

CANバスプロトコルの紹介

コントローラ エリア ネットワーク プロトコル (CAN または CAN バス) は、電子サブシステムを相互にリンクしてネットワーク内で相互作用できるようにする 2 線式 (ツイストペア) の双方向シリアル バス通信方式です。

CAN バスにはマルチマスター機能があり、バス上のどのノードでもネットワーク内の他のノードとの通信を開始できます。

CAN ネットワーク上のすべてのノードは同じ公称ビット レートで動作する必要があります。そうしないと、受信側でエラーが発生します。

CAN仕様は国際規格です。現在、2つのバージョンが使用されています。低速版のCAN 2.0Aは、Basic CANまたはStandard CANとも呼ばれ、ISO11519規格で定義されています。高速版のCAN 2.0Bは、Full CANまたはExtended-Frame CANとも呼ばれ、ISO11898規格で定義されています。

CANバスネットワークでは、通信に2つ以上のノードが必要です。メッセージ（フレーム）は、主にメッセージの優先度を表すID（識別子）と最大8バイトのデータで構成されます。CRC、確認応答（ACK）、その他のオーバーヘッドもメッセージの一部です。CANバスのメッセージフレームを図1に示します。

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

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

1つのCANバスメッセージで最大8バイトのデータを転送できます。DLCフィールド（データ長コード）は、データフィールドに含まれるデータのバイト数を示します。

DLC値が0の場合、リモートフレームと呼ばれる特殊なメッセージフレームであることを示します。リモートフレームは、ネットワーク内の特定のノードにデータを要求するために使用され、これらのフレームには情報は含まれません。ノードが正しいIDを持つリモートフレームを受信すると、そのノードは自動的にネットワークを介してデータを送信します。

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

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

現在サポートされている各HILデバイスには、それぞれ独立したコネクタを備えた2つのCANコントローラが搭載されており、100MHzのリファレンスクロックで動作します。これらの2つのコントローラ（CAN1およびCAN2）は、標準の9ピンD-subタイプ（オス）コネクタを介してCANバスネットワークに接続できます。

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

• HIL602+ ピン配置
• HIL604 ピン配置
• HIL101 ピン配置
• HIL404 ピン配置
• HIL506 ピン配置
• HIL606 ピン配置

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

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

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

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

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

CAN バス プロトコルでは 64 ビット データの送受信がサポートされていますが、HIL デバイス内のすべてのレジスタは 32 ビット長であるため、受信データは 32 ビットに変換され、64 ビット データの送信は 32 ビット データの送信と同じになります。

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

CAN FDコントローラ経由のCANバス

CAN FD コントローラ (現在はHIL506 および HIL606 ) を備えた HIL デバイスは、これらのコントローラが通常の CAN バス コントローラとして動作するように構成できるため、CAN バスの機能が 2 倍になります。

モデル設定で適切なHILデバイスを選択すると、 CANバス設定コンポーネントにコントローラパラメータを定義するための追加タブが表示されます。また、 CANバス送信コンポーネントとCANバス受信コンポーネントでは、CANコントローラ選択のオプションとしてCAN FD1とCAN FD2の値が表示されます。

CANバスのセットアップ

CANバスセットアップコンポーネントを図2に示します。現在サポートされている各HILデバイスには2つのCANコントローラ（CAN1およびCAN2）が搭載されており、CANバスセットアップコンポーネントは、モデルで使用される各HILデバイスに対してこれらのコントローラを設定するために使用されます。

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

CANバスステータス

CANセットアップコンポーネントには、CAN1およびCAN2コントローラのステータスを示す2つの出力（can1とcan2 ）があります。これらのステータスは、通信プロセス中にエラーが発生したかどうかを示します。発生する可能性のあるエラーは、 ACKエラー、ビットエラー、スタッフエラー、フォームエラー、 CRCエラーです。

ACE CAN セットアップ

ACE CANセットアップコンポーネントを図3に示します。これは、車載通信エクステンダーに搭載されたCAN/CAN FDコントローラーの設定に使用されます。

CANバス送信

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

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

スタートビットの値は、フレームのデータフィールド内における信号の位置を指定します。リトルエンディアンバイトオーダーの信号の場合、最下位ビットの位置が示されます。ビッグエンディアンバイトオーダーの信号の場合、最上位ビットの位置が示されます。ビットは鋸歯状にカウントされます。ビッグエンディアンバイトオーダーとリトルエンディアンバイトオーダーのCANメッセージのデータフィールドの詳細については、以下を参照してください。

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

coded_value = (physical_value - offset) / scale

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

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

信号がリストに追加されると、図6に示すようにCANバス送信コンポーネントが表示されます。信号ポートは、モデルの任意の信号処理部分に接続できます。

回路図には複数のCANバス送信コンポーネントを配置でき、各コンポーネントは送信するCANメッセージを1つずつ記述します。複数のメッセージを送信するためにモデルにCANバス送信コンポーネントを追加する場合は、すべてのメッセージに一意のIDが割り当てられていることを確認する必要があります。

CANバス受信

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

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

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

スタートビットの値は、フレームのデータフィールド内における信号の位置を指定します。リトルエンディアンバイトオーダーの信号の場合、最下位ビットの位置が示されます。ビッグエンディアンバイトオーダーの信号の場合、最上位ビットの位置が示されます。ビットは鋸歯状にカウントされます。ビッグエンディアンバイトオーダーとリトルエンディアンバイトオーダーのCANメッセージのデータフィールドの詳細については、以下を参照してください。

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

coded_value = (physical_value - offset) / scale

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

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

信号がリストに追加されると、図9に示すようにCANバス受信コンポーネントが表示されます。信号ポートは、モデルの任意の信号処理部分に接続できます。

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

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

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

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

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

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コントローラ間でメッセージが中継される速度を定義します。送信周期とボーレートの違いは、メトロノームの例で簡単に説明できます。メトロノームは定期的にクリック音を発しますが（送信周期）、そのクリック音は音速でリスナーに伝わります（ボーレート）。

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

ビッグエンディアンおよびリトルエンディアンのバイト順におけるCANメッセージフレームのデータフィールド形式

図1に示すように、1つのメッセージフレーム内で8バイト（バイト0からバイト7）を送信できます。スタートビットパラメータ値は、フレームのデータフィールド内における信号の位置を指定します。リトルエンディアン信号の場合、スタートビットは最下位ビット（LSB）の位置に対応し、ビッグエンディアン信号の場合、スタートビットは最上位ビット（MSB）の位置に対応します。

図12と図13に示す2つの例では、メッセージは3つの信号で構成されていますが、最初の例ではリトルエンディアンバイトオーダー、2番目の例ではビッグエンディアンバイトオーダーです。信号のバイトオーダーがビッグエンディアンかリトルエンディアンのどちらであるかに応じて、各信号に適切なスタートビットを設定する必要があります。

「更新」ボタンをクリックすると、CANメッセージフレームのデータフィールドセクション内の各信号のビット配置が右側の表に表示されます。この表の各行は、CANメッセージの1データバイト（バイト0からバイト5まで）を表します。この例ではデータ長が6バイトであるためです。

図12の場合、信号の値が1の場合、CANバスに現れるデータバイトは16進数で0x01、0x04、0x01、0x00、0x00、0x00となります。一方、図13の場合、0x00、0x41、0x00、0x00、0x00、0x01となります。

仮想HILサポート

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