CAN FD – 概要
CAN FD を選ぶ理由
ノードの数、通信速度、サイクルタイムに対する要求が高まり、従来の CAN（8 データバイトおよびデータ転送速度 1 Mbit/s）の制限によって実現できないケースが見られています。ここで重要な役割を担うのがデータレートで、これはネットワークの拡張範囲やサービスおよびアナログデータの短いデータ長に依存しています。
これらの制限は、日々の運用での妥協策によって回避されています。さまざまなアプリケーションではその妥協策として、システムを複数のネットワークセグメント、さらには並列ネットワークにまで分散させていますが、これは既存技術が常に消耗していることを意味し、設定や設置、メンテナンスが複雑で高コストなソリューションになることも少なくありません。基本的に、高性能な産業用 Ethernet テクノロジーへの転換は可能でしょう。しかしながら、特に時間制御システムでは通常必要とされる投資レベルを増やしたり、システム設定でのデータ構造および思考様式に変更を加えることになり、広範囲なネットワークでは大きな挑戦となることが多く見られます。さらに開発や設定、サービスで使用するツールの変更も求められることから、多くのユーザーが完全な転換を思いとどまっています。
また同時に、すでにあるノウハウを有益な方法で使い続けたいという思いもあります。
ここで役立つのが CAN FD です。CAN FD（CAN with flexible data rate）は、2012 年に Bosch 社が発表し、広く知られている CAN の拡張型プロトコルで、使用できるデータレートとデータ長が大幅に拡大されています。また、メッセージ ID をベースにしたアービトレーション、イベントドリブンのメッセージ送信、ACK ビットを用いて受信したメッセージの確認など、実績のある CAN コンセプトは保持されています。
データレートの向上
従来の CAN で使用されている受信側によるメッセージ確認は、送信したメッセージ内で送信成功を確認することによって、潜在的な送信エラーを素早く検知できたり、極めて短時間にデータ再送できるなど、幅広いメリットをもたらしています。
CAN 識別子をベースとしたメッセージのアービトレーションも、データ送信中の衝突を回避し、たとえバス負荷が高い状況でも優先順位の高いメッセージの遅延を短くすることで、制御アプリケーションにとってのメリットを実現しています。
ただし、この方法を使用した場合、故障を避けるためにサンプリング時にすべてのノードに同じバスレベルが存在している必要があるというデメリットがあります。そのため、わずかなインターバルによってネットワークのなかで最も離れている 2 つのノード間で使用できる十分なシグナル伝搬時間を作り出す必要があります。これには、バスのアクティブ化も含まれます。そのわずかなインターバルそして、結果的にデータレートもネットワークの拡張にそのまま左右されます。最大 1Mbit/s で 40m の拡張が可能ですが、250m 拡張するとその速度は 250kBit/s まで低下します。
CAN FD は、既存の通信技術を変えることなく大幅にデータレートを増加させるため、2 つの異なるビットレートと連動します。制御コマンド（アービトレーション、メッセージタイプ、終了の検出、確認）の「アービトレーションレート」は伝搬速度に依存し、ネットワーク範囲によって異なります。それに反して、2 つ目の「データビットレート」もデータ内容やデータセキュリティに応じて任意で使用されます。現時点では、メッセージ送信者のみがバスを占有します。これはビットタイム内の直接のフィードバックが不要であることを意味します。そのため、実現可能なデータレートの最大値は伝送メディアの伝送特性にのみ依存し、シグナル伝搬には依存しません。CAN FD ネットワークは現在、8 MBit/s での生産的使用が可能ですが、CAN FDスタンダードは最大 15Mbit/s での使用が可能です。このビットレートは、さまざまなテストシステムでもうまく活用されています。
図 1：この例では、合計 42 バイトの設定データが送信されます。従来の CAN でこのデータを送信するには、データ量全体を 8 バイトメッセージで伝送できるようにトランスポートプロトコルを実装する必要があります。この例は、データストリームの制御に最初のデータバイトだけを使用するモデルトランスポートプロトコルをベースとしています。つまり、各 CAN メッセージで最大 7 バイトを使用することができます。実装されているトランスポートプロトコルによっては、制御のために追加のデータフィールドが必要になることがあります。
比較として下側にあるのは、ユーザーデータである 48 バイトの 1 つの CAN FD メッセージで、必要とされる 6 つの CAN メッセージに代わることができます。前述のとおり、CAN FD メッセージではより高速なデータ送信が可能であるため、CAN メッセージと比べて必要とされるバス時間も大幅に短くなります。さらに CAN FD メッセージを 1 つしか使用しないことで、データストリームの管理が大幅にシンプルになります。
2 つのデータレートはそれぞれ個別に、2 つのビットタイミングレジスタを使用する CAN FD コントローラーにセットされます。2 つのデータレート間の切り替えは、プロトコルの 2 つのコントロールビットを使用して実行されます。これまで予約されていた 1 つ目のビットは「Extended Data Length」ビット（EDL）として使用され、そのレセシブレベルにより CAN FD メッセージを定義します。実際のビットレートスイッチは、新たに追加された「Bit Rate Switch」ビット（BRS）によって、サンプリング時により高いビットレートに切り替えられます。逆の切り替えは、CRC 制限ビットのサンプリング時に実行されます。
ユーザーデータの拡張
制御データは、よく知られる低いビットレートを使用して送信されているため、達成可能なデータレートは制限されます。ユーザーデータ領域を 64 バイトまで増やすことによって、高速な転送モードでより多くのデータを送信できるようになり、事実上データレートが上がります。
従来の CAN のデータレートは 8 バイトしかないため、高精度アナログ値の送信、およびさまざまなエンコーディング値やドライブコマンドによる複数軸のロボット制御など、多くのデータアプリケーションにはもはや十分ではありません。さらにサービスデータも追加する必要があるため、８ バイト以上のデータ送信に必要なトランスポートプロトコルのせいで、これまでは有効性が大幅に低下していました。
CAN FD には最大 64 データバイトを使用するためのオプションがあります。そのオプションを使用すると、特にプロセスデータの場合、より大きなデータブロックを 1 つのメッセージで送信することができるため、1 つのプロセスメッセージを使用するだけでさらに複雑なデバイスを完全に制御することができます。サービスデータについては、設定データや同様のデータには 1 つの CAN FD メッセージしか必要とされないことが多いため、トランスポートプロトコルの必要性は少なくなります。
図 2：これは図 1 に表示されている CAN メッセージを 1 つのタイムラインで表示した図で、従来の CAN のデータレートは 250 kBit/s と想定されています。8 バイトのユーザーデータ（この例ではトランスポートプロトコルが 1 バイト、ユーザーデータが 7 バイト）とスタッフビットを最大数含むメッセージの場合、従来の CAN メッセージでは約 500 µs のバス時間が必要です。送信ノードで 6 つのメッセージすべてを遅延なく連続して送信できる場合、42 バイトのユーザーデータの送信にかかる 3 ミリ秒の間、バスは完全にブロックされます。
それに対して、48 バイトのユーザーデータ、250kBit/s のアービトレーションレート、そして 2MBit/s のデータビットレートの CAN FD メッセージで占有するバスはたったの約 365 µ秒です。ここにも最大数のスタッフビットが含まれています。
データ送信が極めて短時間に行われることでレスポンス時間が大幅に短くなるため、CAN システムのリアルタイムの動作も向上し、同時にデータレートが増えて、データ管理の複雑さが軽減されます。
制御データが不必要に拡大することを防ぐため、CAN FD でもデータ長コードには 4 ビットしか使用していません。0 から 8 までの値は直接従来の CAN から取得されます。これまで未定義だった値（9 から 15、つまり 1001 から 1111）は、新しく拡張されたデータ長に使用されます。0 から 8 バイトに加えて、12、16、20、24、32、48 バイトもユーザーデータに使用することができます。これらと異なるデータ長はありません。つまり使用されていない領域には「充填値」が入っている必要があります。
CAN FD を使用することで、データ領域の高速送信に加えて、効率的に使用できるデータレートの大幅な増加が可能になり、サイクルタイムを大きく短縮することができます。このように 500kBit のアービトレーション、4Mbit のデータ送信、64 データバイトの CAN FD ネットワークにより、5 MBit/s を超える効率的なデータレートを実現します。
リアルタイム機能
複数あるデータパケットをひとつのメッセージにまとめることで、多大なコストをかけて個別のメッセージをそれぞれ同期させる必要がなくなり、データ管理がかなりシンプルになります。従来の CAN と比べてより大きなデータパケットを高速送信することで、8 バイトの CAN メッセージに必要とされる時間とおおよそ同じ時間で 8 倍のデータ量（64 バイト）の転送が可能です。この方法で優先順位の高いメッセージをより早く送信することができ、リアルタイム機能も改善されています。
データセキュリティ
データセキュリティは重要なテーマです。CAN FD は、CAN と比べてデータパケットサイズが大きくなっているにもかかわらず、同様のデータセキュリティに対する要件を満たしています。たとえば、適応したアルゴリズムと共により長い CRC チェックキーを使用することで実現しています。送信されるデータバイト数に応じて、3 つの CRC アルゴリズムのうちの 1 つを使用します。1 つは最大 8 データバイトのメッセージ向けで以前の CRC 式、あとの 2 つは最大 16 データバイトまたは 16 データバイト以上のメッセージによる 2 つの拡張アルゴリズムです。CAN コントローラーが使用するアルゴリズムは、データ長コードによって決定されます。
データセキュリティ向上のため、推奨事項がさらに実装されています。結果として、CAN FD メッセージの CRC はいつでもスタッフビットから開始し、さらなる 5 ビットの後に次のスタッフビットが含まれます。CAN のスタッフビットのルールとは逆で、前のビットのビット値とは無関係です。それぞれのスタッフビットの値は、その前のビットの逆の値です。
下位互換性
CAN から高速な通信システムに乗り換える際のデメリットの 1 つとして、完全な変換でよく見られる条件があります。それは CAN ネットワーク上のすべてのユーザーが、新しいシステム（EtherCAT など）に適合する必要があることです。その代わりにマシンコントローラーの拡張や、種類が異なる複数のネットワークの使用が可能になります。どの方法にもメリットとデメリットがあります。CAN FD を使用することで、次のように変化がより緩やかな別の方法もあります。CAN FD コントローラーは CAN ノードとしての使用もできるため、すべてのネットワークノードを順番に CAN FD 対応デバイスに置き換えることができます。ネットワーク全体が CAN FD に対応するようになった時点から、CAN FD のメリットを最大限活用することができます。特に顧客独自のデバイスや社内で開発されたデバイスなどでは、使用可能なノードに自由に置き換えられないネットワークメンバーの使用が多いため、特殊用途の機械には注目すべきメリットです。