CAN FDと従来のCANの違い

まとめ：

CAN FDと従来のCANの違いは何ですか? データ転送とリアルタイムパフォーマンスの点での違いは何ですか?

自動車エレクトロニクスと産業オートメーションの活発な発展に伴い、CAN バス上のデバイスの数とデータ量が大幅に増加し、CAN バスに大きな課題をもたらしています。より高い帯域幅とデータスループットを満たすために、CAN FD (柔軟なデータレートを備えた CAN) が誕生しました。では、CAN FDと従来のCANの違いは何でしょうか? データ転送とリアルタイムパフォーマンスの点での違いは何ですか?

基本コンセプト:

CANFD (Controller Area Network with Flexible Data-Rate) は、従来の CAN (Controller Area Network) プロトコルをベースに改良された通信プロトコルです。CAN と比較して、CAN FD は帯域幅と伝送速度が高く、より多くのデータ伝送をサポートできます。また、さまざまなデータ伝送のニーズを満たすために、より多くのフレーム形式もサポートしています。

一般に、従来の CAN から CAN FD に切り替える理由は 3 つあります。

01 CAN FD は、ビットレートを向上させながら、より短い CAN フレームを提供します

- 遅延の低減。

- リアルタイムパフォーマンスの向上

- より高い帯域幅

02 CAN FD は CAN フレーム内に 8 ～ 64 バイトのより多くのデータを保持できます

- システムのオーバーヘッドが比較的少ない = データスループットが向上

- より大きなデータオブジェクトを送信する場合、ソフトウェアはよりシンプルかつ効率的になります

03 CAN FD はより高性能な CRC アルゴリズムを備えています

- 検出されないエラーのリスクの軽減

CAN FD は CAN バスのデータ量負荷が徐々に限界に達した後の製品であるため、この記事では CAN FD を従来の CAN と比較し、CAN FD について詳しく紹介することを目的としています。

01. CAN FDと従来のCANのデータフレームフォーマット

図 1 従来の CAN フレーム (上) と CAN FD フレーム (下) の比較。どちらのフレームもシングルバイトデータであり、この場合、CAN FD フレームのビットレートは増加しません。両方のフレームが、フレーム開始 (SOF) ビットから 11 アービトレーションビット全体まで同一であることがわかります。調停後、クラシック CAN のリモート送信要求ビット (RTR ビット) (A のマーク) と CAN FD フレームのリモート要求置換ビット (RRS ビット) が更新されます。データフレームの場合、このビットは両方のフレームフォーマットで常にドミナント (0) です。通常、論理 0 および 0 ボルトの信号として定義されるドミナントビットは、下部の太い黒い線 (B のラベル) で表されます。

図 1 従来の CAN フレームと CAN FD フレームの比較

リモート送信要求ビット (RTR ビット) に続くビットは明示的識別子拡張ビット (IDE ビット) で、フレームが 11 ビットアービトレーションを使用する基本フレームフォーマットであることを示します。この記事では、29 ビットアービトレーションを使用する EF Extended Frame Format (EFEFF) については説明しないことに注意してください。

IDE ビットの後には r0 ビット (予約ビット) があり、従来の CAN フレームフォーマットでは常にこのビットが優勢です。CAN FD フレームフォーマットでは、このビットはリセッシブ (C を参照) であり、フレームが従来の CAN フレームではなく、現在 CAN FD (CAN Flexible Data-rate) と呼ばれる予約済みフォーマットの CAN フレームであることを示します。つまり、このビットは、CAN フレームがクラシック CAN フレームであるか、CAN FD フレームであるかを示します。ISO11898-1 標準のリリース以来、このビットは、ISO11898-1 標準の以前のバージョンでは r0 ビットと呼ばれていたものではなく、FDF ビット (フレキシブルデータフォーマットビット) と呼ばれるようになりました。以前の文書またはデータシートの r0 ビットへの参照を参照してください。これは、ISO11898-1 の 2015 年版の FDF ビットと同じです。

02. CANFD用の追加ビット

FDF ビット/r0 ビット (以降、FDF ビットと呼びます) の後に、FD フォーマットの予約ビット (res) とレガシー CAN フォーマットのデータ長コードビット (DLC) が続きます。つまり、以前の ISO11898-1 標準に従って製造されたすべてのレガシー CAN コントローラは CAN FD フレームを誤って解釈し、その結果、レガシー CAN コントローラでエラーフレームが発生します。巡回冗長検査 (CRC) デリミタ (図 1 で D とマーク) の後は、CAN Classic と CAN Fd のビットパターンは同一です。つまり、レガシーフォーマットと FD フォーマットはどちらも、次のフレームが開始される前に同じ終了パターンを使用します。

すべての CAN FD コントローラは、レガシー CAN フレームと CAN FD フレームの混合を処理できます。これは、レガシー CAN フォーマットのみを使用するレガシー CAN コントローラだけでなく、既存のシステムでも CAN FD コントローラの使用を開始できることを意味します。すべての古いレガシー CAN コントローラが CAN FD コントローラに置き換えられると、レガシー CAN フレームと CAN FD フレームを混合したり、2 つのタイプのうち 1 つだけを使用したりすることが可能になります。

CAN FD フレームの FDF ビットの後には予約ビットがあります。FDF ビットが CAN レガシーから CAN FD フォーマットへの移行を示すのと同様に、このビットの設定は将来のプロトコルを暗黙的に示します。将来の協定はまだ決まっていない。レガシー CAN フォーマットの r0/FDF ビットが CAN FD フォーマットを示すために使用されるまでに 25 年かかったということは注目に値します。

予約ビットの後には BRS ビット (ビットレート変換) があります。この追加ビットにより、CAN FD フレームを 2 つの異なるフォーマットで送信できるようになります。BRS ビットがドミナントで送信される場合、すべてのビットは、図 1 に示すアービトレーションで使用されるのと同じビットレートで送信されます。BRS ビットがリセッシブの場合、フレームフォーマットはこのビットの後、CRC デリミタまでのより高いビットレートを使用します。

BRS ビットの後に ESI ビット (エラーステータスインジケータ) が続き、通常はこれが優勢です。CAN FD フレーム送信ノードがエラーパッシブになると、このビットは劣性送信され、送信ノードに重大な通信問題があることを示します。このビットがより広範な用途でどのように使用されるかは不明ですが、自動車メーカーは必要に応じて採用しています。

これらの 3 つの新しいビット (予約ビット、BRS ビット、ESI ビット) の後には、CAN フレーム内のデータバイト数を示す 4 つの DLC ビットがあります。表 1 は、これらの 4 ビットが CAN フレーム内のデータバイト数を示すためにどのように使用されるかを示しています。従来の CAN フレームは最大 8 バイトのデータを保持できます。表からわかるように、8 バイトを超える DLC コードを送信できますが、送信される CAN フレームには 8 バイトのデータのみが配置されます。表をよく見ると、DLC 9 ～ 15 は CAN FD フォーマットが異なることがわかります。9 から 63 までのバイト数には 6 ビット DLC が必要で、64 バイトまでには 7 ビット DLC が必要です。妥協案は、4 ビット DLC を維持し、CAN FD フレームのバイト長数 (12、16、20、24、38、48、および 64) を制限することです。

03. CANFDによりデータ転送速度が大幅に向上

DLC ビットの後のデータ (図 1 は 1 データバイトを持つ CAN フレームを示しています)。このデータの前後のビットは、固定長の任意の数のデータバイトです。この例では、1 バイトのデータを送信するには、従来の形式では 55 ビットが必要ですが、CAN FD 形式では 70 ビットが必要です。最悪の場合、フレーム内に複数のスタッフィングビットが含まれる可能性もあります。フレームに同じレベルで 5 ビットを超える連続ビットがある場合、プロトコルは極性を反転してフレームに余分なビットを追加し、レベルの変化を使用してサンプリングポイントを再同期できるようにします。

再同期のために余分なビットを追加および削除するこのプロセスはスタッフィングと呼ばれ、これらのビットは CAN プロトコルでスタッフィングビットとしてマークされます。表 1 の最後の 2 列からわかるように、各 CAN フレームにより多くのデータを詰め込むことでデータ伝送効率が向上します。効率方程式は、オーバーヘッド内のパディングビットの最悪の場合の数を想定しています。Classical CAN はオーバーヘッドが低いため、CAN FD に比べて若干効率的です。CAN FD フレームのバイト数を 8 バイトから 64 バイトに増やすことにより、効率を 50% から 88% に高めることができます。

この表には、さまざまなフレームフォーマットで使用される CRC コードも含まれています。従来の CAN フォーマットでは、すべてのフレームが同様の長さであるため、すべてのフレームタイプに 15 ビット CRC エンコーディングが使用されます。64 バイトフレームは 8 バイトフレームの 8 倍であるため、CAN FD フレームは少し複雑です。この問題を解決するために、CAN FD フレームでは 2 つの異なる CRC 長が使用されます: フレームが 16 バイト以下の場合は 17 ビット CRC-17、CAN フレームが 20 バイト以上の場合は CRC-17 21 の CRC-21 を使用します。ビット。

これは、2 つの追加ビットとスタッフィングカウンタの 4 ビットおよび固定スタッフィングビットを備えた CRC であり、CAN FD フレームを従来の CAN フレームよりも長くします。従来の CAN フレームでは CRC セグメントに最大 3 ビットのスタッフビット、制御セグメントにさらに 3 ビットを含めることができるため、この比較は完全に公平ではないと主張する人もいます。

CAN FD フレームの CRC セグメントの追加ビットにより、データコンテンツの保護が強化され、システムセキュリティが高いため、クラシック CAN から CAN FD に移行する十分な理由になります。

CAN フレーム内のデータが 8 バイトを超えると、効率が向上するためデータスループットが増加します。これが、クラシック CAN から CAN FD に移行するもう 1 つの理由です。

04.データ伝送効率とリアルタイム性のバランスをとるには

長い CAN フレームを使用すると効率は向上しますが、CAN フレームや 1 秒あたりのフレーム数が少ないと、通信の遅延が増加し、リアルタイムのパフォーマンスが低下することに留意することが重要です。この問題を軽減し、データスループットを向上させるために、CAN FD フレームのビットレートを従来の CAN で可能なものよりも高めることができます。

これまで、CAN FD は CAN フレーム全体で同じビットレートを持つと説明してきました。前述したように、レセシブ BRS ビットでは、フレームのデータ部分でより高いビットレートに切り替える必要があります。

図 2 では、3 番目の CAN フレームが追加されています。この 3 番目のフレームは、中央の CAN FD フレームと同じ内容の CAN FD フレームですが、この例では、中央の CAN FD フレームの 2 倍のデータレートで送信されます。

図 2 CAN FD フレームにデータレートが含まれない / 2 倍のデータレートが含まれる

内容が同じであるため、同じ DLC とデータが得られますが、CAN FD がより高いビットレートで送信される場合、BRS ビットはリセッシブに送信されます (E を参照)。BRS ビットは CRC 計算に含まれており、CAN-ID、DLC、データが同じであっても、2 つの異なる CRC 内容が生成されます。

図 2 からわかるように、より高いビットレートで送信される最初のビットは ESI ビットで、その後に DLC、データバイト、CRC ビットが続きます。より高いビットレートで送信される最後のビットは CRC デリミタです。このことから、より高いビットレートは CAN Fd フレームのデータセグメントだけでなく、周囲のビットにも適用されることがわかります。

図 3 は、前述のフレームの下に新しいフレームがあることを除いて、図 2 と同じです。この新しいフレームの内容は他のすべてのフレームと同じですが、ビットレートはアービトレーションビットレートの 8 倍です。変動は、固定ビットレートまたはダブルビットレートの CAN FD フレームと比較して比較的大きくなります。

単一バイトのデータだけでなく、フレームの DLC および CRC 部分 (合計約 40 ビット) のビットレートも向上していることがわかります。

図 4 は、上部に 8 バイトのレガシー CAN フレームがある 3 つの CAN フレームを示しています。中央は 64 バイトの CAN FD フレームで、下の CAN フレームは同じ CAN FD フレームの内容ですが、ビットレートが向上しています (8 倍高速)。

図 3 は図 2 に基づいており、ビットレートが 8 倍に増加した CAN FD フレームを使用しています。

図 4 からわかるように、データが増えると CAN フレームの送信時間が長くなり、他の優先度の高い CAN フレームの送信が開始されなくなります。リアルタイムのパフォーマンスを維持するには、ビットレートを上げて CAN フレームの長さを短縮し、CAN フレームが通信回線を占有する時間を短縮し、他の優先度の高いフレームが通信にアクセスするのを防ぐ必要があります。

図 4 の上部は 8 バイトの従来の CAN フレームです。

中央には、同じビットレートの 64 バイトの CAN FD フレームがあります。

一番下は、ビットレートが 8 倍に増加した 64 バイトの CAN FD フレームです。

結論として、ビットレートが高い CAN FD はリアルタイムパフォーマンスを向上させます。これは、ビットレートが高いほど CAN フレームの送信時間が短くなり、通信の遅延が減少するためです。各フレームでより多くのデータを送信することでデータスループットを向上させることができますが、より高いビットレートと組み合わせないとリアルタイムパフォーマンスが低下します。多くの場合、プログラミングでは 64 バイト長の CAN フレームが使用されますが、これは通常、システムが停止し、リアルタイム制御が実行されていないときに行われます。リアルタイム要件がない場合でも、より高いビットレートを使用してデータスループットを向上させ、ダウンロード時間を短縮することは有益です。

出典| インテリジェントコネクテッドビークルネットワーク

おすすめ