CANオープン

CANopen は、オートメーションで使用される組み込みシステム用の通信プロトコル スタックおよびデバイス プロファイル仕様です。OSIモデルでは、CANopen はネットワーク層を含む上位の層を実装します。CANopen 標準は、アドレス指定スキーム、いくつかの小さな通信プロトコル、およびデバイス プロファイルによって定義されるアプリケーション層で構成されます。通信プロトコルは、メッセージのセグメント化/セグメント化解除のための単純なトランスポート層を含む、ネットワーク管理、デバイス監視、およびノー​​ド間の通信をサポートしています。データ リンクと物理層を実装する下位レベルのプロトコルは通常、コントローラ エリア ネットワーク(CAN) ですが、他の通信手段 ( Ethernet Powerlink、EtherCATなど) を使用するデバイスも CANopen デバイス プロファイルを実装できます。

基本的なCANopenデバイスおよび通信プロファイルは、CAN in Automationによって公開されたCiA 301仕様に記載されています。^[1]より特殊なデバイスのプロファイルはこの基本プロファイルの上に構築されており、 I/Oモジュール用のCiA 401 ^{[2]やモーション制御用のCiA 402 [3]}など、CAN in Automationによって公開された他の多数の標準で指定されています。

すべての CANopen デバイスは、制御ソフトウェアに特定の標準機能を実装する必要があります。

• 通信ユニットは、ネットワーク内の他のノードとのメッセージングのためのプロトコルを実装します。
• デバイスの起動とリセットは、ステート マシンによって制御されます。ステート マシンには、初期化、事前動作、動作、停止の各状態が含まれている必要があります。状態間の遷移は、デバイスにネットワーク管理 (NMT) 通信オブジェクトを発行することによって行われます。
• オブジェクトディクショナリは、16 ビットのインデックスを持つ変数の配列です。さらに、各変数には 8 ビットのサブインデックスを設定できます。変数は、デバイスを構成し、その環境を反映するために使用できます (つまり、測定データが含まれます)。
• デバイスのアプリケーション部分は、ステート マシンが動作状態に設定された後、実際にデバイスの必要な機能を実行します。アプリケーションはオブジェクト ディクショナリ内の変数によって構成され、データは通信層を介して送受信されます。

CANopen デバイスには、デバイスの構成と通信に使用されるオブジェクト ディクショナリが必要です。オブジェクト ディクショナリのエントリは、次のように定義されます。

• インデックス、辞書内のオブジェクトの16ビットアドレス
• オブジェクト名（オブジェクト タイプ/サイズ）、エントリ内のオブジェクトのシンボリック タイプ（配列、レコード、単純な変数など）
• 名前、エントリを説明する文字列
• Type は変数のデータ型（または配列のすべての変数のデータ型）を指定します。
• 属性は、このエントリのアクセス権に関する情報を提供します。読み取り/書き込み、読み取り専用、書き込み専用のいずれかになります。
• 必須/オプションフィールド（M/O）は、デバイス仕様に準拠するデバイスがこのオブジェクトを実装する必要があるかどうかを定義します。

ブール値、整数、浮動小数点数などのオブジェクト ディクショナリ値の基本データ型は標準で定義されています (ビット サイズは、関連する型定義のインデックス範囲 0x0001 ～ 0x001F にオプションで格納されます)。また、文字列、配列、レコードなどの複合データ型も標準で定義されています (インデックス範囲 0x0040 ～ 0x025F で定義されます)。複合データ型は 8 ビット インデックスでサブインデックス付けできます。配列またはレコードのサブインデックス 0 の値は、データ構造内の要素数を示し、UNSIGNED8 型です。

たとえば、基本デバイスプロファイルCiA 301 ^[4]で標準化されたデバイス通信パラメータは、インデックス範囲0x1000～0x1FFF（「通信プロファイル領域」）にマッピングされます。この領域の最初のいくつかのエントリは次のとおりです。

適切なツールがあれば、電子データシート（EDS）に基づくデバイスのオブジェクトディクショナリの内容をデバイス構成ファイル（DCF）にカスタマイズして、デバイスを特定のCANopenネットワークに統合できます。CiA 306 ^[5]によると、EDSファイルの形式はINIファイル形式です。今後はXMLスタイルの形式が登場し、CiA 311 ^[6]で説明されています。

CANopen のデータリンク層であるCAN バスは、11 ビットの ID、リモート送信要求 (RTR) ビット、および 0 ～ 8 バイトのデータで構成される短いパッケージのみを送信できます。CANopen 標準では、11 ビットの CAN フレーム ID を 4 ビットの機能コードと 7 ビットの CANopen ノード ID に分割します。これにより、CANopen ネットワーク内のデバイスの数は 127 に制限されます (0 はブロードキャスト用に予約されています)。CAN バス標準の拡張 (CAN 2.0 B) では、29 ビットの拡張フレーム ID が許可されていますが、実際には拡張 ID 範囲を必要とするほど大きな CANopen ネットワークはほとんど見られません。

CANopen では、CAN フレームの 11 ビット ID は、通信オブジェクト ID、または COB-ID と呼ばれます。送信衝突が発生した場合、CAN バスで使用されるバス アービトレーションにより、最小の ID を持つフレームが最初に遅延なく送信されます。時間的に重要な機能に低いコード番号を使用すると、遅延が最小限に抑えられます。

CANopen フレームの内容:

11 ビットの識別子を持つデータ フレームは、「ベース フレーム形式」とも呼ばれます。

デフォルトの CAN-ID マッピングでは、最初の 4 ビットに機能コード (NMT、SYNC、EMCY、PDO、SDO...) を割り当てることでフレームをソートし、重要な機能が優先されるようにします。ただし、このマッピングは特別な目的に合わせてカスタマイズできます (基本通信に必要な NMT と SDO を除く)。

この規格では、特定の CAN-ID がネットワーク管理と SDO 転送用に予約されています。一部の機能コードと CAN-ID は、デバイスの初期化後に標準機能にマッピングする必要がありますが、後で他の用途に設定することもできます。

シンプルなネットワーク構造の場合、CANopen はメッセージ識別子の定義済み割り当てをサポートします。

送信と受信の指示はデバイスの観点から行われます。したがって、ネットワーク上のデバイスへのクエリは、0x600+nodeid を送信し、0x580+nodeid を返します。^[1]

CANopen ノード間のメッセージングでは、さまざまな種類の通信モデルが使用されます。

マスター/スレーブ関係では、1 つの CANopen ノードがマスターとして指定され、スレーブにデータを送信または要求します。NMT プロトコルは、マスター/スレーブ通信モデルの例です。

SDO プロトコルではクライアント/サーバー関係が実装されており、SDO クライアントはデータ (オブジェクト ディクショナリ インデックスとサブインデックス) を SDO サーバーに送信し、SDO サーバーは要求されたデータ (指定されたインデックスのオブジェクト ディクショナリの内容) を含む 1 つ以上の SDO パッケージで応答します。

プロデューサー/コンシューマーモデルは、ハートビート プロトコルとノード ガーディング プロトコルで使用されます。プロデューサー/コンシューマーのプッシュ モデルでは、プロデューサーは特定の要求なしにコンシューマーにデータを送信しますが、プル モデルでは、コンシューマーはプロデューサーにデータを要求する必要があります。

NMT プロトコルは、状態マシン変更コマンド (デバイスの起動と停止など) を発行したり、リモート デバイスの起動やエラー状態を検出したりするために使用されます。

モジュール制御プロトコルは、 NMT マスターがデバイスの状態を変更するために使用されます。このプロトコルの CAN フレーム COB-ID は常に 0 です。これは、機能コード 0 とノード ID 0 を持っていることを意味し、ネットワーク内のすべてのノードがこのメッセージを処理することを意味します。コマンドの対象となる実際のノード ID は、メッセージのデータ部分 (2 番目のバイト) で指定されます。これは 0 になることもあり、その場合はバス上のすべてのデバイスが指定された状態になることを意味します。

ハートビート プロトコルは、ネットワーク内のノードを監視し、それらが動作していることを確認するために使用されます。ハートビート プロデューサー (通常はスレーブ デバイス) は、バイナリ機能コード 1110 とそのノード ID (COB-ID19 = 0x700 + ノード ID) を含むメッセージを定期的に送信します。フレームのデータ部分には、ノードの状態を示すバイトが含まれます。ハートビート コンシューマーはこれらのメッセージを読み取ります。メッセージが特定の時間制限 (デバイスのオブジェクト ディクショナリで定義) 内に到着しない場合、コンシューマーは、たとえばデバイスをリセットしたり、エラーを表示したりするアクションを実行できます。フレームの形式は次のとおりです。

CANopen デバイスは、起動時に自動的に初期化状態から動作前状態に移行する必要があります。この移行が行われると、単一のハートビート メッセージがバスに送信されます。これが起動プロトコルです。

スレーブ監視には、ノード ガーディングと呼ばれる応答/返信スタイル (プル モデル) プロトコルが存在します。

SDO プロトコルは、リモート デバイスのオブジェクト ディクショナリの値の設定と読み取りに使用されます。オブジェクト ディクショナリにアクセスするデバイスは SDO サーバーで、リモート デバイスにアクセスするデバイスは SDO クライアントです。通信は常に SDO クライアントによって開始されます。CANopen の用語では、通信は SDO サーバーから開始されるため、オブジェクト ディクショナリからの読み取りは SDO アップロードになり、ディクショナリ エントリへの書き込みは SDO ダウンロードになります。

オブジェクト ディクショナリの値は CAN フレームの 8 バイト制限よりも大きくなる可能性があるため、SDO プロトコルは長いメッセージのセグメント化とセグメント解除を実装します。実際には、これらのプロトコルには SDO ダウンロード/アップロードと SDO ブロック ダウンロード/アップロードの 2 つがあります。SDO ブロック転送は標準に新しく追加されたもので、プロトコル オーバーヘッドをわずかに減らして大量のデータを転送できます。

クライアントからサーバーへ、およびサーバーからクライアントへの各 SDO 転送メッセージの COB-ID は、オブジェクト ディクショナリで設定できます。オブジェクト ディクショナリのアドレス 0x1200 - 0x127F に最大 128 個の SDO サーバーを設定できます。同様に、デバイスの SDO クライアント接続は、0x1280 - 0x12FF の変数で設定できます。ただし、事前定義された接続セットは、起動直後 (Pre-operational 状態) でもデバイスの設定に使用できる SDO チャネルを定義します。このチャネルの COB-ID は、受信の場合は 0x600 + ノード ID、送信の場合は 0x580 + ノード ID です。

ダウンロードを開始するために、SDO クライアントは、SDO チャネルの「受信」COB-ID を含む CAN メッセージで次のデータを送信します。

• ccsは SDO 転送のクライアント コマンド指定子です。0 は SDO セグメントのダウンロード、1 はダウンロードの開始、2 はアップロードの開始、3 は SDO セグメントのアップロード、4 は SDO 転送の中止、5 は SDO ブロックのアップロード、6 は SDO ブロックのダウンロードです。
• nは、メッセージのデータ部分に含まれるデータを含まないバイト数であり、eとsが設定されている場合にのみ有効です。
• eが設定されている場合は、高速転送を示します。つまり、交換されるすべてのデータはメッセージ内に含まれます。このビットがクリアされている場合、メッセージはセグメント化された転送であり、データが 1 つのメッセージに収まらず、複数のメッセージが使用されます。
• sが設定されている場合、データサイズが n (e が設定されている場合) またはメッセージのデータ部分で指定されていることを示します。
• インデックスは、アクセスするデータのオブジェクト辞書インデックスであり、リトルエンディアンでエンコードされます。
• サブインデックスはオブジェクト辞書変数のサブインデックスです
• データには、高速転送の場合にアップロードされるデータ（e が設定されている）、またはアップロードされるデータのサイズ（s が設定され、e が設定されていない）が含まれます。多くの場合、リトルエンディアンでエンコードされます。

プロセス データ オブジェクト プロトコルは、さまざまなノード間でリアルタイム データを処理するために使用されます。デバイスとの間で、1 つの PDO あたり最大 8 バイト (64 ビット) のデータを転送できます。1 つの PDO には複数のオブジェクト ディクショナリ エントリを含めることができ、1 つの PDO 内のオブジェクトは、マッピングおよびパラメーター オブジェクト ディクショナリ エントリを使用して構成できます。

PDO には、送信 PDO と受信 PDO (TPDO と RPDO) の 2 種類があります。前者はデバイスからのデータ用 (デバイスはデータ プロデューサー) で、後者はデバイスに送信されるデータ用 (デバイスはデータ コンシューマー) です。つまり、RPDO を使用するとデバイスにデータを送信でき、TPDO を使用するとデバイスからデータを読み取ることができます。定義済みの接続セットには、4 つの TPDO と 4 つの RPDO の識別子があります。構成により、512 個の PDO が可能になります。

PDO は同期または非同期で送信できます。同期 PDO は SYNC メッセージの後に送信されますが、非同期メッセージは内部または外部トリガーの後に送信されます。たとえば、RTR フラグ付きの空の TPDO を送信することで、必要なデータを含む TPDO を送信するようにデバイスに要求できます (デバイスが TPDO 要求を受け入れるように構成されている場合)。

RPDO を使用すると、たとえば 2 つのデバイスを同時に起動できます。同じ RPDO を 2 つ以上の異なるデバイスにマップし、それらの RPDO が同じ COB-ID でマップされていることを確認するだけです。

Sync-Producer は、Sync-Consumer に同期信号を提供します。Sync-Consumer は信号を受信すると、同期タスクの実行を開始します。

一般に、同期 PDO メッセージの送信時間を固定し、同期オブジェクトの送信周期と組み合わせることで、センサー デバイスがプロセス変数をサンプリングするように調整し、アクチュエータ デバイスが調整された方法でアクチュエーションを適用できることが保証されます。

同期オブジェクトの識別子はインデックス 1005h で使用できます。

通常、タイムスタンプ オブジェクトは、時刻を 6 バイトのフィールドとして表します。つまり、午前 0 時からのミリ秒数 (最大 27 ビット、32 ビット フィールドに格納) と、1984 年 1 月 1 日以降の日数を符号なし 16 ビットで表します (これは 2163 年 6 月 7 日にオーバーフローします)。

特に伝送速度が低下した大規模ネットワークにおける、時間に敏感な一部のアプリケーションでは、非常に正確な同期が求められます。ローカル クロックをマイクロ秒単位の精度で同期する必要がある場合があります。これは、ローカル クロックの不可避的なドリフトを調整するために特殊な形式のタイムスタンプ メッセージを使用するオプションの高解像度同期プロトコルを使用することで実現されます。

高解像度のタイムスタンプは、1 マイクロ秒の解像度で unsigned32 としてエンコードされます。つまり、時間カウンターは 72 分ごとに再起動します。これは、高解像度のタイムスタンプ (オブジェクト 1013h) を PDO にマッピングすることによって構成されます。

緊急メッセージは、デバイス内部の致命的なエラー状況の発生によってトリガーされ、関係するアプリケーション デバイスから他のデバイスに高い優先度で送信されます。このため、緊急メッセージは割り込みタイプのエラー アラートに適しています。緊急テレグラムは、「エラー イベント」ごとに 1 回のみ送信できます。つまり、緊急メッセージは繰り返さないでください。デバイスで新しいエラーが発生しない限り、それ以上の緊急メッセージを送信する必要はありません。CANopen 通信プロファイルで定義された緊急エラー コードにより、エラー レジスタとデバイス固有の追加情報がデバイス プロファイルに指定されます。

ID 1 およびノー​​ド ID 2 用に構成されたマスターと 2 つの圧力トランスデューサ スレーブ間の通信のサンプル トレース。

電子データシート (EDS) は、CiA306 で定義されたファイル形式で、デバイスの通信動作とオブジェクト ディクショナリ エントリを記述します。これにより、サービス ツール、構成ツール、開発ツールなどのツールがデバイスを適切に処理できるようになります。

これらの EDS ファイルは、CiA CANopen 適合テストに合格するために必須です。

2007 年末より、CiA311 で XDD と呼ばれる新しいXMLベースの形式が定義されています。XDD はISO標準 15745 に準拠しています。

• PDO : プロセス データ オブジェクト - 入力と出力。回転速度、電圧、周波数、電流などの値。
• SDO : サービス データ オブジェクト - 構成設定、ノード ID、ボー レート、オフセット、ゲインなど。
• COB-ID : 通信オブジェクト識別子
• CAN ID : CAN 識別子。これは、バス上のすべての CAN メッセージの先頭にある 11 ビットの CAN メッセージ識別子です。
• EDS : 電子データシート。これは、INI スタイルまたは XML スタイルでフォーマットされたファイルです。
• DCF : デバイス構成ファイル。これは、ノード ID とボーレートの設定を含む変更された EDS ファイルです。

• コントローラ エリア ネットワークは、 CAN バスに関する記事です。
• J1939
• デバイスネット
• IEEE1451 規格
• トランスデューサーML

1. ^ CiA 301 CANopen アプリケーション層仕様、CAN in Automation から無料でダウンロード可能
2. ^ CiA 306 CANopen 電子データシート (EDS) 仕様
3. ^ CiA 311 CANopen XML-EDS仕様
4. ^ CANopen Basicsの定義済み接続セット[8]
5. ^ CiA 401 汎用 I/O モジュール用 CANopen デバイス プロファイル仕様、CAN in Automation から無料でダウンロード可能
6. ^ CiA 402 モーションコントローラおよびドライブ用 CANopen デバイスプロファイル (IEC 61800-7-201/301 と同じ)

• CANopen Origins - Esprit プロジェクト ASPIC 1993 (Bosch、ニューカッスル大学、ロイトリンゲン応用科学大学)
• CANopen について (canopensolutions.com)
• CANopen ネットワークにおける識別子の使用
• CanFestival - オープンソースの CANopen マルチプラットフォーム フレームワーク
• CanOpenNode - マイクロコントローラと Linux 用のオープンソース CANopen フレームワーク
• Lely CANopen - マスターとスレーブ用のオープンソースの CANopen ライブラリ
• openCANopen - オープンソースの CANopen マスター
• CANopen スタック プロジェクト - マイクロコントローラ用の柔軟なオープンソース CANopen スタック
• Python 用 CANopen
• CANニュースレター - CAN、CANopen、J1939に関する情報
• CANopen教育ページ
• CANopen の基礎入門 (www.canopen-solutions.com 内)
• CANopen-Lift コミュニティの Wiki
• CANeds: EDA および XDD ファイルの無料エディター
• オートメーションにおけるCANのオンラインポータル
• CANopen - アプリケーション層と一般的な通信プロファイル