技術情報

CANopenは、上位層 (higher-layer)CAN通信プロトコルです。CANopenは、ロボット、医療、輸送、自動車、航空宇宙などのリアルタイム産業アプリケーションにおいて組み込みネットワークのための標準化された高度に構成可能なソリューションとして広く使用されています。

KvaserのCANインターフェースは、テクニカルアソシエイトソフトウェアと共に、CANopenアプリケーションとの通信と構成をセキュアに行う方法を提供します。

CANopen対応インターフェース

Kvaser CANインターフェースは、CANopen通信のための理想的なソリューションを提供します。
その特徴としては：

• スウェーデン製のハードウェア、ハイパフォーマンス機能、厳密な生産体制と高品質により長期間の信頼性を確保できます。真のフィット＆フォーゲットソリューションを提供します。
• エンクローズドインターフェース、または組み込みネットワークに対応するPCIベースのボード...選択はあなた次第です。
• フリーのユニバーサルで上位互換APIにより、ソフトウェアの統合を容易にします。

CANopenインターフェースを検索

アプリケーションに適したソフトウェア

Kvaserのテクニカルアソシエイトのネットワークは、CANopenシステムのマネージメント、サーボの設定、ソフトウェアの開発など、業界で信頼されているソリューションを提供します。

ソフトウェアツール

• emotas GmbH － CANopen Device Explorer (英語)
• port GmbH － CANopen Design Tool (英語)
• port GmbH － CANopen Device Monitor (英語)

システム設計＆インテグレーションサービス

• Olympus Controls (英語)
• Actronic Solutions (英語)

CANopenプロトコルスタック

• TK Engineering － CANopen Stack (英語)
• port GmbH － CANopen Source Code Library (英語)
• emotas GmbH － CANopen Master Stack (英語)

CANopen FDプロトコルスタック

• emotas GmbH － CANopen FD Stack (英語)

SERVOコンフィギュレーション

Copley Controls
Xenus, Accelnet, Stepnet Product configuration
copleycontrols.com/en/products (英語)

Elmo Motion Controls
Composer － Servo drives tuning / auto tuner software for SimplIQ and ExtrIQ servo drives
elmomc.com/product/composer (英語)

Advanced Motion Controls
DigiFlexR DriveWare software for setup and configuration of digital servo drives
a-m-c.com/experience/products/software/driveware (英語)

CANopen仕様の紹介

CANopenは、一連のデバイスプロファイルによって補完される上位層(Layer 7)のCAN通信プロトコルです。リアルタイムの産業アプリケーション、ロボット工学、医療、輸送、自動車、航空宇宙分野における組み込みネットワークのための標準化された高度に設定可能なソリューションとして広く使用されています。CANopenデバイスプロファイルファミリは、標準化された通信メカニズムと様々なアプリケーションに必要なデバイス機能を規定しています。Automation International Users and Manufacturers Group(CiA)は、CANopen規格を管理しています。

CANopenの利点

• アプリケーションおよびネットワークイベントサービスを通して柔軟性の高いコンフィギュレーション機能を備えた組み込みアプリケーションのための標準化。
• 標準化されたデバイス、インターフェース、およびアプリケーションプロファイルにより、高いモジュール性を備えた完全なCANopenシステムの容易な統合および相互運用性と互換性を提供。
• 多くの国際的なベンダによってサポートされている高度に標準化されたプロトコル。
• リアルタイムのデータ交換、同期と非同期、サイクリックと非サイクリック、イベントドリブン。
• システムエンジニアとアプリケーション開発者がCANopenベースプロファイルを拡張し、拡張されたデバイスコンフィギュレーションおよび診断機能を提供できる効率的なアドレス指定スキームを備えたオブジェクトディクショナリ。
• オブジェクトディクショナリと組み合わせたSDOメッセージングは、システム設計者にネットワークを介したデバイスコンフィギュレーションの手段を提供。
• システム設計者がプロセスデータ通信、エラー表示、およびネットワークコントロールのために必要なネットワーク機能をプログラムできる様々な通信オブジェクト。
• 専用のSYNCおよびTIMESTAMPオブジェクトを通した効率的な同期。
• ノードガーディングを通した強化したノード監視と診断。
• 堅牢性、フォールトトレランス、およびリカバリのための効率的で柔軟なstate machine (状態機械)の実装。

CAN in Automation Groupが発表した"CANopen FD"に関する最新情報

CANopenプロファイル

CiAは、CANopenのデバイスと通信プロファイルの仕様を一連のドキュメントで管理しています。CANopenに関するCiAのドキュメントとしては、3つのカテゴリに分かれています：

1. CiA仕様：ハードウェアおよびソフトウェアにおけるプロトコルとプロファイルを実装するための機能性。
2. CiA推奨事項：最適なソリューションに関する情報。
3. CiA実装とユーザガイドライン：CiA仕様と勧告の使用方法に関する説明。

基本プロファイルは、CiA 301 Specificationというドキュメントで定義されています。"CANopen application layer and communication profile"と名付けられ、CANopenのアプリケーション層を規定しています。この仕様には下記が含まれています：

• データタイプ、エンコーディングルール、CANopen Object Dictionaryのオブジェクト
• CANopenの通信サービスとプロトコル
• CANopenのネットワークマネージメントサービスとプロトコル
• CANopen通信プロファイル - 物理層
• 定義済の通信オブジェクト識別子コネクションセット、緊急に関連するオブジェクト、タイムスタンプと同期通信オブジェクト

基本的なCiA 301プロファイル仕様は、他のCiAドキュメントにより補完および拡張され、より専門的なデバイスや機能のためのデバイス、アプリケーション、インターフェースのプロファイルを規定しています。

いくつか挙げてみましょう：

• CiA 302：CANopen追加アプリケーション層機能
• CiA 303-1：ケーブル配線とコネクタのピン配列
• CiA 303-3：インジケータの仕様
• CiA 306：CANopen電子データシート仕様
• CiA 309：他のネットワークからのCANopenアクセス
• CiA 315：CANopen汎用フレーム
• CiA 401：汎用I/OモジュールのCANopenデバイスプロファイル
• CiA 402：ドライブとモーションコントロールのためのCANopenデバイスプロファイル

CANopen Device Model

すべてのCANopenデバイスは汎用デバイスモデルに準拠しているため、異なるデバイスは同じCANopen規格で記述されます。CANopenデバイスモデルの3つのコンポーネントは次のとおりです：

• 通信
• object dictionary
• アプリケーション

通信

CANopenでは、ノード間のメッセージ送信に異なる通信モデルを使用しています：

Producer/Consumer model：ブロードキャストコネクションで、プッシュモード (プロデューサノードが特定の要求なしにコンシューマノードに情報を送信)とpull mode (コンシューマノードがプロデューサノードに特定の情報を要求)で動作します。

Client/Server model：SDOプロトコルを使用し、クライアントノードがサーバノードにデータ(object dictionary index)を要求し、サーバノードが指定されたインデックスのオブジェクトコンテンツを送信することで応答する。

Master/Slave model：マスターノードは、いつでもスレーブノードにデータを送信またはスレーブノードからデータを要求することができます。例：NMT プロトコル通信。

CANopen通信ユニットは、ノード間のバスを介して通信オブジェクトの送受信を提供するために必要な通信インターフェースとプロトコルソフトウェアで構成されています。異なるCANopen通信objectは、プロセスデータ、ネットワークマネージメント、ノード監視、同期信号エラー制御、緊急メッセージなどの様々なタイプの通信を実行するために使用されます。これらのオブジェクトとその記述は、下記の表にリストされています。

CANopenフレーム

CANopenフレームは、次のフィールドで構成されます。

• 11ビットCAN フレームは、idまた、CANopen 通信object識別子(COB-ID)とも呼ばれます。さらに、4ビットの機能コード(CANopen 通信objectを表す)と7ビットのノードidに分割されます。
• 1ビットリモート伝送要求 (RTR)
• 4ビットのデータ長
• 0～8バイトのデータ

Object Dictinary

Object Dictionary (OD)は、CANopenが構築される中心的な概念です。これは定義されたCANopen objectのグループであり、ネットワークを介してオブジェクトアクセスにindexesとsub indexesを使用します。object dictionaryは、アプリケーションとデバイス間のインターフェースであり、デバイスとの構成と通信のメソッドを提供します。object dictionaryにオブジェクトエントリとして格納される情報には、以下のようなものがあります。

• 通信とアプリケーションのプロファイルパラメータ
• 標準化されたデバイスプロファイルパラメータ
• マニュファクチュアラー固有のデバイスプロファイルパラメータ
• デバイスプロファイルの静的データタイプ
• デバイスプロファイルの複合データタイプ
• コンプレックスおよびスタティックデータタイプ
• マニュファクチュアラー固有のデータタイプ
• その他

上記のオブジェクトの説明から、標準デバイスプロファイルとデータタイプの仕様で指定された標準デバイス機能を拡張することで、デバイスの機能を強化できることは明らかです。CANopen規格に基づいて事前に定義された方法で、独自のマニュファクチュアラー固有のプロファイルとデータイプを追加することで、それを実現できます。

object dictionaryエントリのフィールドには次のものがあります：

Main Index：object dictionaryのエントリを直接指す16ビットのインデックス。単純な変数の場合、インデックスは変数値を直接参照し、複合タイプの場合はrecordsまたはarrays全体を指します。

Sub index：8ビットのsub indexで、メインインデックスが指す複合なデータ構造の中のarray entriesまたはrecord値などの個々のデータフィールドを指します。

Object：エントリ内のオブジェクトのタイプを示すシンボリック名。例：VAR、ARRAY、RECORDなど。

Name：エントリを説明する文字列。

Type：エントリのデータタイプモディファイア (修飾子)。例：UNSIGNED32, BOOLEANなど

属性 (Attribute)：このエントリのアクセス権の値。例：読み取り/書き込み、読み取り専用、書き込み専用

Mandatory/Optional (必須/オプション)：デバイスがこの特定のオブジェクトエントリを実装することが必須かオプションか。

様々なobject parameter groupsは、以下のようにインデックスレンジで構成されています：

通信プロフィールのエントリ例

複合または構造化データタイプを参照するためのsub indexの例

これらのエントリは、シングルチャネルのRS-232インターフェースのためのものであり、その通信パラメータはindex 6092Hの単一の構造化データタイプとして存在します。個々の通信パラメータは、sub index 6092Hに存在し、そのレンジは0～1です。

上記のobject dictionaryエントリに対するCプログラミング言語構造の定義は次のとおりです:

CANopenのネットワークマネージメント

CANopenのネットワークマネージメントは、Master/Slaveの通信モデルを使用しています。ネットワーク全体が"state machine"として実装され、1つのデバイスがNMT Master、他のデバイスがNMT Slavesとして指定されています。NMT Masterは、NMT Slavesの状態をコントロールおよび監視します。NMT Slavesは、NMT Masterによってトリガーされたstate transitions (状態遷移)を通してCANopenネットワーク実装の様々なフェーズに入ります。

このような状態遷移のために、マスターからスレーブに対してブートアッププロトコル、モジュールコントロールプロトコル、ハートビートプロトコル、ノードガーディングなどの特定のNMTプロトコルを使い状態変更コマンドが発行されます。NMT masterは、特定のノードまたはすべてのノードにNMTコマンドコードを送信して状態を変更します。

NMT Slave state machineの初期状態遷移シーケンスは、Power-OnまたはPower-Offイベントからの回復から始まり、その後、デバイスのInitialization (初期化)が続きます。その後、NMT slaveデバイスは、自動的にPre-Operational (動作前)状態に移行します。エラー制御および診断中の内部デバイスリセット (アプリケーションのリセットおよび通信のリセット)イベントも、NMTスレーブデバイスを初期化状態にした後、動作前状態にします。また、エラー制御や診断の際に行われるInternal Device Reset (アプリケーションのリセットおよび通信のリセット)イベントでは、NMT slaveデバイスが初期化状態にした後、動作前状態になります。この遷移の前にデバイスは、Boot-Upプロセスを示すためにブートアッププロトコルを使用してブートアップメッセージをバスに送信します。

運用前の状態においてアプリケーションコンフィギュレーションツールは、SDO 通信を使用してNMT slavesを構成およびパラメータ化できます。デバイスは、まだ動作していないので、この状態ではPDO通信は許可されません。

状態がPre-Operational (運用前)からOperational (運用)に変更されると、ノード内のすべての通信オブジェクトがアクティブになり、PDO通信とSDO通信の両方がoperationalノード間で許可されます。このステージの間では、SDOを介したobject dictionaryへのアクセスも可能です。ノードの状態が停止状態に変更されると、PDOとSDOの両方の通信が停止します。

CANopenでのノード状態監視

NMT masterは、リモートフレームを使用してスレーブデバイスを定期的にポーリングして現在の状態を取得し、ネットワークデータベースに記録されている以前の状態と一致させます。不一致やPDO送信の欠如は、適切なエラーコードで示されアプリケーションは、デバイスのリセットやエラー表示などの適切なアクションを実行します。これはNode Guardingと呼ばれ、Node Guarding Protocolを使用して実装されます。NMT slavesは、Life Guardingと呼ばれる手法を使用して、事前定義された時間間隔でノードGuardingフレームの受信を内部的にチェックすることで、NMT masterの不在を検出します。

最新のデバイス設計では、NMT slave (Heartbeat Producer)が周期的にNMT master NMT(Heartbeat Consumer)にハートビートメッセージを送信するノード監視にHeartbeat Protocolを使用します。これらのメッセージ間の間隔は、設定が可能で、両方のデバイスのobject dictionariesのHeartbeat producerタイムオブジェクトで設定されます。ハートビートメッセージがこの制限時間内に到着しない場合、プロデューサは、ダウンと見なされ、コンシューマはデバイスのリセットやエラー表示などの修復アクションを実行します。

Pre-Defined Connection Set (定義済のコネクションセット)

1つのmasterと最大127のslavesを持つ単純な通信構造の場合、CANopenは、Pre-Defined Connection Set (定義済のコネクションセット)と呼ばれるCANメッセージ識別子の事前定義された割り当てを提供します。このスキームの全体的な目的は、ピア・ツー・ピアコネクションのみを必要とするシンプルなネットワークでのコンフィギュレーションオーバーヘッドを削減するものです。この定義済みのmaster-slaveコネクションスキームは、デバイスごとに次のように通信オブジェクトの割り当てをサポートします：

• 1つのEmergencyオブジェクト
• SYNCおよびTIMESTAMPオブジェクト
• 1つのSDOコネクション
• NMTノード監視用のNMT (node guarding/heartbeat)
• 最大4つの送信PDOと4つの受信PDO

電子データシートとCANopenシステムコンフィギュレーション

電子データシート(EDS)は、CANopenデバイスのために定義された通信機能とオブジェクトを記述した標準化された電子ファイルです。このベンダが作成したファイルには3つの領域があります：

• EDSファイルに関する情報
• 一般的なデバイス情報
• デフォルト値を含むObject dictionary

EDS fileは、CANopenデバイスのコンフィグレーションおよびネットワーク設定のツールとして使用できます。

CANopenとKvaser

Kvaserは、Kvaser CANopenスタック を開発しました。これは、ハイパフォーマンスなCANopenネットワークを実現するためのユーザフレンドリーでメモリ効率に優れたAPIです。標準規格に完全に準拠し、CANopen masterおよびslave機能を完全にサポートしています。

産業界におけるCANopenの状況

Vector Informatik GmbHは、CANopenネットワークの分析とシミュレーションのための最高のソフトウェアツールの1つであるCANalyzerを開発しています。

Port GmbHは、以下のようなCANopenツールの豊富なコレクションを開発しています。

• CANopenデバイス開発のためのCANopenデザインツール
• CANopen Master/Slave Protocol Library
• CANopenモジュールとプロファイル
• CANopenデバイスモニタ
• CANopenゲートウェイサーバ

National Instrumentsは、CANopenアプリケーションの開発を支援する1ポートのCシリーズCANopenインターフェースモジュールを提供しています。

CANopenのオープンアーキテクチャを活用し、高度に標準化された詳細な推奨事項、ガイドライン、および実装を利用するCANopen NodeのようなオープンソースAPIやプロトコルスタックだけでなく、他にも多数のCANopen商用ツールがあります。