「CANopenプロトコル」

弊社では、CAN （Controller Area Network）通信を用いたFA-M3向けのモジュール「SZ20」を販売しているほか、パソコンとCAN通信を行うアプリケーションの開発など、これまでの案件でCAN通信を扱う機会がありました。昨年、このCAN通信を発展させた通信規格「CANopen」を調査する機会があり、当時入社半年の私が担当することとなりました。
私たちはCANopenについてまったく未知でしたので、CANopenとは？というところから調査を行うことになりました。今回のソフテックだよりでは、その調査した内容をご紹介いたします。なお、CANについては過去のソフテックだよりで触れていますので、併せてご覧ください。（ソフテックだより 第65号（2008年5月7日発行）技術レポート「CANのWindowsソフトウェアへの導入」、ソフテックだより 第131号（2011年2月2日発行）技術レポート「CAN通信モジュール紹介」）

CANopenとは、組み込み向けの通信プロトコルです。2004年にドイツの「CAN in Automation（以下CiAと称します）」によって規格化され、今日まで発展を続けてきました。CiAは、多様な分野でCANopenデバイスを使用できるよう、各分野向けに通信仕様書を策定しオープンにしてきました。現在その仕様書数は30を超え、その対象分野はFA、医療、車両、鉄道など多岐に渡ります。CANを下地にした通信プロトコルは、DevicenetやSAE J1939などCANopen以外にも存在しますが、CANopenはそれ以上に汎用的です。また、CANopenデバイスは、どのような組み合わせでも使用でき、プラグ&プレイでの拡張が容易というオープンネットワーク（※1）の特徴があります。さらには、誰でも開発に参加できます。

CANopenの通信プロトコルは、CiA301というドキュメントにまとめられていて、これは誰でも入手することが可能です。今回のソフテックだよりは、基本的にこのCiA301を参考にまとめています。なお、さらに踏み込んでCANopenデバイスを製造し販売するためには、CiAへのベンダー登録が必要で、その際割り振られるベンダーIDと、CiA302というプログラミングマニュアルが必要です。

ここではCiA301に基づき、CANとCANopenの違いをご説明します。まず、OSI（Open Systems Interconnection）参照モデルを例にすると、CANは物理層とデータリンク層に該当し、CANopenはアプリケーション層に位置します。（図1）すなわち、通信のルールだけを定めたのがCANで、そこで扱われるデータの使い道を定めたのがCANopenと表現できます。その例として、CAN IDとオブジェクトディクショナリについてご紹介します。

図1. OSI参照モデルに基づくCANとCANopenの比較

まず、CANとCANopenにおいて、データを送信するフレームの中には、11 bitか29 bitのCAN IDと最大8 byteのデータフィールドが含まれます。CAN IDは、「より小さいIDほどネットワーク上で高い優先度を持つ」というルールがあり、それはCANopenも同様です。ここでの決定的な違いは、そのCAN IDの用途です。
CANでは、個々のIDをどう用いるかは、全て開発者の裁量に依存しますが、CANopenでは、CiA301である程度定義されています。例えば、ネットワーク上で最も優先度の高いID = 0は、CANopenデバイス本体の制御命令です。
IDを自由に決められないことは不便に感じられますが、一方で大規模なシステムや、拡張を繰り返すシステムでは、ID管理の煩わしさが軽減されることも多いはずです。

また、オブジェクトディクショナリはCANopenの特長の一つになります。（図2）これは、最大65535のインデックスと、一つ当たり最大256のサブインデックスから成るデータセットで、デバイスの動作などを全てデバイス内部に定義した辞書のようなものです。他のCANopenデバイスやアプリケーションからの読み書きを受けつつ、自らを制御することが出来ます。

図2. OSI参照モデルに基づくCANとCANopenの比較

この機能の利点は、デバイスの動作をあらかじめアドレッシングして定義しておけることで、CANopenネットワークとその外側の独立性を高め、異なる機器やネットワークとの接続も簡便になります。すなわち、CANopen外部のネットワークからは、ユーザーがCAN IDやメッセージを意識せずに、デバイスの制御ができることになります。この特長を有さないCANでは、デバイスの動作や送受信したCANメッセージの使い道を、開発者が1から構築しなければいけません。

このように、CANopenはCANの特長そのままに、ユーザーの利便性を図った通信プロトコルと言えます。

ここでは、CANopenネットワーク上で使用されるコミュニケーションオブジェクト（※2）と、そのオブジェクトを使用したときのデバイスの関係についてご説明します。

4-1. コミュニケーションオブジェクト

4-2. CANopenデバイスの関係

4-3. 具体的なネットワーク例

本号を通じて、CANopenについて、少しでも興味をお持ちいただけましたら幸いです。なお、CANopenデバイスでシステムを構築される場合、EDS（Electronic Data Sheet）ファイルを用いた事前検討が可能です。EDSファイルはオブジェクトディクショナリの機能を列挙したファイルですので、それを購入前に入手できれば、机上シミュレーションが可能になります。もし、本ソフテックだよりをご覧くださった方で、CANopenデバイスの使用を検討されている場合は、各CANopenデバイスのベンダーに問い合わせてみてはいかがでしょうか？

CANopenデバイスは、ユーザーのネットワーク構築の簡略化や利便性を図った規格と言えますが、このプロトコルスタックを1から開発するという視点で見ると、難しい開発であると感じました。しかしながら、こういった開発を行うことにはとても面白みも感じます。今回は調査だけでしたが、機会があればCANopenデバイス開発に関与させていただければと思います。

最後までお読みいただきありがとうございました。