CANベースのマルチノード・システムを構成するトランシーバーIC、最適な製品を選択するための検証手法とは?
概要
本稿では、CAN(Controller Area Network)に対応するトランシーバーの評価方法について説明します。紹介するのは、CANベースのマルチノード・システムで使用するトランシーバー製品を選択するためのシステム・レベルの検証手法です。その手法を採用することよって、あるCANノードから別のCANノードにデータを転送する際に起こり得る問題を回避することができます。本稿を参考にし、ぜひCANベースのシステムに対する理解を深めてください。そうすれば、各種のマルチノード・システムで使用すべきCAN対応のトランシーバー製品を的確に選択できるようになるはずです。
はじめに
CANは高い堅牢性を備える通信規格です。これを採用すれば、様々なセンサーや機械、コントローラの間で双方向の通信を実現することが可能になります。CANに対応するインターフェースは堅牢性が高く、バスの競合を効果的に処理できます。そのため、産業用オートメーション、ホーム・オートメーション、車載システムなどで広く使用されています。
旧来の規格であるCAN 2.0は、8バイトのペイロード、最高2Mbpsのデータ・レートをサポートしています。ただ、重要性の高い通信においては、2Mbpsのデータ・レートでは不十分なケースがあります。そのため、標準化された新たな通信プロトコルとしてCAN FD(Flexible Data Rate)が提案されました。このプロトコルは、最高10Mbpsという高速なデータ・レートをサポートしています。
データ・レートの面で柔軟性に優れるCAN FD
旧来のCANとCAN FDの主な違いとしては、データ・レートが挙げられます。CAN FDのデータ・レート(1秒間に送受信されるビット換算のデータ量)は従来のCANの5倍に達します(データ・ペイロードだけの場合で10Mbps、アービトレーション用のデータのビット・レートは互換性を確保するために1Mbpsに制限)。また、CAN FDのメッセージ・ペイロードのサイズは、旧来のCANの8バイトから64バイトに拡張されています。
CAN FDを採用した場合、センサーにおいて、ペイロードの大きさに応じてデータ・レートを変更するといったことが行えます。例えば、最新の工場において、データ・レートを高い値に設定し、ペイロードの容量を大きくとったとします。そのようにすれば、旧来のCANを使用する場合と比べて、システム・レベルの動作の面で多くのメリットを得ることが可能になります。
CANによる通信の基本
図1に示したのは、CANをベースとする通信ノード(シングルノード)の例です。ご覧のように、CANに対応するコントローラとトランシーバーという2つの主要なコンポーネントで構成されています。
CANコントローラは、CANベースの通信におけるデータ・リンク層に相当します。一方、CANトランシーバーは物理層に当たります。
CANのプロトコルにおいて、ロジック・レベルの0はドミナント・ビット、ロジック・レベルの1はリセッシブ・ビットと呼ばれています。CANは差動プロトコルであり、CANHとCANLの電位差によって送受信する信号のロジック・レベルが決まります。両者の電位差が1.5Vより大きい場合、CANレシーバーはそのビットをロジック・レベルの0であると認識します。一方、同電位差が200mV未満である場合、CANレシーバーはそのビットをロジック・レベルの1として扱います。図2は、CANトランシーバーのTXDピンによってロジック・レベルの1と0に対応する信号を連続的に送信している様子を示したものです。また、それに対応するCANバスのレベル(CANHピンとCANLピン)も示してあります。CANHとCANLの電位差に基づき、レシーバーはRXDピンに信号をループ・バックします。

続いて、CANのデータ・リンク層について見てみます。この層では、制御された状態でビット・ストリームを送信するためのデータ・フレームを生成します。また、エラーの検出やバスの競合の解決といった処理も担います。図3に、CANのフレームの標準的なフォーマットを示しました。
データ・フレームは、最初のドミナント・ビットであるSOF(Start of Frame:フレームの開始)から始まります。続く11ビットの識別子は各ノードに固有のアドレスです。IDEはフレームのフォーマットを表します。このビット・フィールドがロジック・レベルの0である場合、CANの標準フォーマットを採用していることになります。一方、ロジック・レベルの1である場合、それは拡張フォーマットであることを表しています。次のrOは予約ビットです。DLCのフィールドは、送信するデータのバイト数を表します。CAN 2.0の標準的なフレームでは最大8バイトを送信することが可能です。受信側のノードは、バスにドミナント・ビットを送信することで、このデータ・フレームをアクノレッジします。EOF(End of Frame:フレームの終了)は1つのリセッシブ・ビットであり、1つのデータ・フレームの終わりを表します。
CANトランシーバー製品を選択する際には、何らかの評価を行うことになるでしょう。ほとんどの場合、その方法としては、ファンクション・ジェネレータによってCANトランシーバーのTXDピンにビット・ストリームを送信するというものになるはずです。この方法は、シングルノードのCANトランシーバーの評価には適しています。しかし、遠距離の通信を行うCANベースのマルチノード・システムを開発する際には不十分だと考えられます。つまり、システムに適したCANトランシーバーを選択するためには、CANコントローラとCANトランシーバーの両方を網羅したテスト手法が必要になります。以下、なぜそのようなシステム・レベルのテスト手法が必要になるのか説明します。
アービトレーションに関する方法論
マルチノードのシステムでは、なぜシステム・レベルのテスト手法が必要になるのでしょうか。その主な理由としては、CANのプロトコルで定義されているアービトレーション機能が挙げられます。この機能は、2つのノードがバスを同時に占有しようとしたときに働きます。すなわち、その際のバスへのアクセスは、データが壊れないように(非破壊的に)ビット単位のアービトレーションが行われている状態で実行されます。最初の識別子のビット・データとして0(ドミナント)を送信するノードは、他のノードが1(リセッシブ)を送信する間、CANバスの制御を保持してメッセージの送信を完了させます。図4は、2つのノードを対象としてアービトレーションが行われている様子を示したものです。

図において、ノード1とノード2はCANバスを介して互いに接続されています。CANHとCANLの信号は両方のノードに共通です。TXD1とRXD1はノード1の信号であり、TXD2とRXD2はノード2の信号です。ご覧のとおり、ノード1とノード2において最初の3ビットの値は同じです。いずれも、1、0、1に設定されています。続く4ビット目の値は、ノード2では1、ノード1では0になっています。ノード1がドミナント・ビットであることから、こちらがアービトレーションによって優先されます。つまり、ノード1はすべてのメッセージを送信し続けます。そのメッセージは、ノード2によってアクノレッジされます。ノード1がメッセージの送信を完了したら、今度はノード2がメッセージの送信を開始します。そしてノード1は、そのメッセージをアクノレッジします。
各ノードには固有の識別子(ID)が割り当てられています。それら11ビットの識別子はアービトレーションのプロセスで使用されます。それらのデータはコントローラによってリードバックされ、メッセージの送信に関する優先度が識別されます。CAN FDにおいて、アービトレーション用のデータのビット・レートは、データのビット・レートと同じ値にすることも異なる値にすることも可能です。CAN 2.0では、両者のビット・レートは同じ値にする必要がありました。
CAN 2.0を採用したシステムでは、ビット・レートの値を標準的な値として推奨されている1Mbpsよりも高く設定し、データ転送の高速化を図っているケースがあります。一方、CAN FDを採用したシステムでは、データのビット・レートは最高10Mbpsですが、アービトレーション用のビット・レートは1Mbpsに制限されています。11ビットの識別子とSOFが含まれるアービトレーションのフェーズでは、同期を確立するために全送信ビットがリードバックされます。
CANのノードでは、CANのバスで観測されたエッジで同期がとられます。ただ、バス・ラインにおける信号の伝搬時間により、複数のノードの間には位相のずれが生じます。メディア・アクセス制御のために行われるCANの非破壊的なアービトレーションでは、任意の2つのノードにおける位相のずれを1ビットに相当する時間の1/2未満に抑える必要があります。この公称下限値によって、公称ビット・レートとバス長の上限値が決まります。つまり、RXDの立上がり時間と立下がり時間、CANトランシーバーのループ遅延、ケーブルが関連することになります。ビット・レートとして10Mbpsといった高い値を使用する場合、伝搬遅延と立上がり時間/立下がり時間は50ナノ秒未満でなければなりません。このような理由から、CAN FDにおけるアービトレーションのビット・レートは1Mbpsに制限されているのです。結果として、多数のノードを使用する場合でも、同期について大きなマージンを確保することが可能になります。
但し、CAN FDは新たなプロトコルです。まだ、CANをベースとするすべてのシステムに実装されているわけではありません。つまり、CAN FDに対応するコントローラを使用できなかったり、システムに適用する際にかかるコストが許容されなかったりするケースも存在します。そのような場合には、旧来のCANに対応するコントローラが使われることもあるでしょう。そうしたシステムでは、センサーからの情報が非常に重要であったり、ノード間のケーブル長が短かったりする可能性があります。そうした場合、CANのノードはより高いビット・レート(2Mbps以上)で通信を行わなければならないかもしれません。ただ、立上がり時間/立下がり時間の対称性とトランシーバーの伝搬遅延によって、データ通信速度の上限値が制限される可能性があります。
CANトランシーバーの評価に必要なシステム・レベルのテスト
ここからは、CANトランシーバー「MAX33012E」の評価結果を基に説明を続けることにします。このICは、20mのケーブルを使用した場合に最高13.3Mbpsのデータ・レートを実現できることがテストによって確認されています。図5からわかるように、TXD2のビット幅は75ナノ秒(13.3Mbpsに対応)、RXD2のビット幅は72ナノ秒です。コントローラは、TXDのビット幅の80%のポイントでサンプリングを行います。そのため、RXDの立上がり時間/立下がり時間とループ遅延を含めたRXDの最小ビット幅は60ナノ秒となります。図5を見ると、受信ビットの幅は72ナノ秒であることがわかります。つまり、MAX33012Eは条件を満足しています。同ICは、より高いビット・レートで機能するだけの十分な堅牢性を備えています。このような条件下でも、CANコントローラが何らかのエラーを検出することはなく、データ通信が継続されます。

図6は、競合他社の製品を13.3Mbpsで動作させた場合の結果です。このICの場合、送信ビット幅は75ナノ秒(13.3Mbpsに対応)で、受信ビット幅は送信ビット幅の80%未満(48ナノ秒)となっていました。そのため、アービトレーション・フェーズにおけるビット・データの送信は失敗に終わっています。通信エラーが生じ、最終的にはシステムが動作を停止してしまいました。

この種のデータ送信エラーについて検証するためには、どのようなテストが必要でしょうか。それは、複数のCANコントローラ、CANトランシーバー、長いケーブルを含む完全なシステム・レベルのテストです。
まとめ
本稿では、CANトランシーバーを対象とするシステム・レベルのテストについて説明しました。この種のテストを実施すれば、システムのデータ送信において将来的に発生する可能性がある問題を検出することができます。言い換えれば、必要なタイミングと電圧の仕様を満足するCANコントローラとケーブルを使用してCANトランシーバーの評価を行うことで、そうした問題を回避することが可能になります。CANベースのシステムの堅牢性は、システム内の各コンポーネントの性能が累積された結果によって左右されます。1つのCANトランシーバーだけを対象として評価を行っても、システムの性能を正確に把握することはできません。また、システムの性能をあらかじめ検証によって確認しておけば、障害が生じたシステムを交換/刷新するのと比べてはるかに高い費用対効果が得られます。CANトランシーバー製品を選択する際には、事前にシステム・レベルのテストを実施することを強くお勧めします。
著者について
{{modalTitle}}
{{modalDescription}}
{{dropdownTitle}}
- {{defaultSelectedText}} {{#each projectNames}}
- {{name}} {{/each}} {{#if newProjectText}}
-
{{newProjectText}}
{{/if}}
{{newProjectTitle}}
{{projectNameErrorText}}