CANopen プロトコルの概要 - Vector

CANopen プロトコルの概要
Version 1.4
Application Note AN-JON-1-1100
制限
要約
公開文書
本アプリケーションノートは、CANopen がどのようなものであるかを知るためのプロトコル基本コン
セプトをまとめたものです。 詳細については、CiA が規定しているプロトコル仕様書を入手されるこ
とをお薦めします。
目次
1 概要 .........................................................................................................................................................2
1.1 歴史 .....................................................................................................................................................
1.2 特徴 .....................................................................................................................................................
2 標準化されたモデル構造...............................................................................................................................4
3 デバイスモデル .............................................................................................................................................5
4 ネットワーク物理層........................................................................................................................................5
5 Object Dictionary .........................................................................................................................................6
6 通信手法 ......................................................................................................................................................7
7 ネットワークマネージメント .............................................................................................................................9
8 Pre-defined コネクションセット ....................................................................................................................10
9 CANopen システムのコンフィグレーション ....................................................................................................11
10 デバイスプロファイル .................................................................................................................................12
11 最後に ......................................................................................................................................................13
12 連絡先 ......................................................................................................................................................13
Copyright © 2003 - Vector Informatik GmbH
http://www.vector-japan.co.jp
1
Introduction to CANopen
1
概要
CANopen は、CAN (Controller Area Network) システムをベースとし、ネットワークモデルの第 7 層 (Application
レイヤー) に通信とデバイスプロファイルを定義したものです。
CANopen 仕様は標準化され、フレキシビリティーとコンフィグレーション可能な組込ネットワークアーキテクチャーと
して、鉄道分野、医療機器、産業機械、農業機械、トラック/バス、船舶/航空、FA などの様々な分野で採用されてい
ます。また、従来の RS-232/485 など独自規格で設計された組込ネットワークから置き換えられるケースも多くあり
ます。仕様書は通信関連と各種デバイスの機能別にプロファイルが標準化されています。
現在、これらの仕様は、国際的なユーザとベンダーのグループである CiA (CAN in Automation) がまとめており、
ライセンスフリーなオープンネットワークとして採用することが可能です。
1.1
歴史
以下にこれまでの経緯を簡単に紹介します。
07/`92 ASPIC*による ESPIRIT III プロジェクトがスタート。CAN がフィールドバスシステムに適していることから物
理層として採用。通信プロファイルとデバイスプロファイルの開発が始まる。*ASPIC:Automation and
Control System for Production Units Using an Installation Bus Concept
06/`94 プロファイルの制定を”CAN in Automation (CiA) ”という国際的なユーザとベンダー企業のグループが行う
こととなる。
09/`94 ASPIC による最初の報告。
02/`95 “CANopen”と命名。
04/`95 CANopen 対応デバイスが発表される。
10/`95 通信プロファイル DS-301 が制定される。
02/`96 最初のデバイスプロファイルとして、DS-401 (Generic I/O) が発表。
04/`96 マルチベンダーシステムが発表。
~`97 いくつかのデバイスプロファイルとプログラマブルデバイスのためのフレームワーク WD-302 が開発される。
06/`99 DS-301 がヨーロッパの標準規格として採用される。
`01
CANopen 仕様 Ver. 4.01 がヨーロッパ規格協会で EN50235-1 として認可される。
12/`04 CANopen DS-301 Ver. 4.02 が、CiA の Web ページで無償で閲覧可能となる。
現在
いくつものデバイスプロファイルとフレームワークが規格化され、世界中で多くの製品が登場し
様々な装置に採用されている。
Application Note AN-JON-1-1100
2
Introduction to CANopen
特徴
1.2
CANopen は、CAN をベースとしたオートメーションシステムのためのプロファイルセットと言えます。特徴は以下の
とおり。
•
標準化されたオープンネットワーク
•
プロトコルのオーバーヘッドがなく、リアルタイム通信を実現
•
ノード構成が自由で、高いスケーラビリティー
•
高い互換性
•
“Interbus”、“Profibus”に似たプロファイルコンセプトを採用
•
世界中の多くの企業が採用
CANopen プロトコルでできることはなにか?
•
ネットワーク構成の標準化
•
全てのデバイスパラメーターへのアクセス
•
ノード間の同期通信
•
周期およびイベントドリブンでのデータ通信と非同期通信が混在
Application Note AN-JON-1-1100
3
Introduction to CANopen
2
標準化されたモデル構造
ISO/OSI ネットワークモデルで見ると CANopen は、多くのデバイスプロファイルを含めて CAN (第 1 と第 2 層) を
ベースとした第 7 層の Application レイヤー部を規定した通信プロファイルとさらにその上位にデバイス種類ごとに
用意されたデバイスプロファイルグループです。
Device
Profile A
Device
Profile B
Device
Profile C
CAN をベースとしたこの構造は、ほぼ DeviceNet と同じと考えられ
ます。ただ互いに CAN メッセージでの通信ではありますが、内部の
モデル構造が異なります。
ISO/OSI Layer 7: Application - CANopen
Communication Profile
ISO/OSI Layer 2: Data Link
ISO/OSI Layer 1: Physical
DSP 405 - Device
Profile for IEC 1131
Programmable
DS 401 - Device
Devices
Profile for Generic I/
O Modules
(3)
CAN
Figure 1:ISO/OSI ネットワークレイヤー
”CiA DS-301 “EN 50325-4”という仕様には全
ての基本概念、データタイプ、エンコーディング
ルールと動作について書かれています。
仕様書は、DS-301:通信プロファイルとそれを
補う形で、DS-3xx 番台の仕様書が用意されて
います。これらが CANopen デバイス必要な共
通仕様で、DS-4xx 番台にデバイスの種類ごと
に詳細なデバイスプロファイル仕様が用意され
ています。
これらの仕様書は、CiA メンバーの各関連ベン
ダー企業が参集した技術部会で現在でも検討
されています。
Application Note AN-JON-1-1100
DSP 302 Framework for
Programmable
CANopen
Devices
(2)
DS 301 - Application
Layer and
Communication
Profile
(1)
Further frameworks
(application field
specific)
ISO 11898
Figure 2 : CANopen 仕様書体系
4
Introduction to CANopen
デバイスモデル
3
Object Dictionary
Application
PDO
Index
CAN
Communication
Process
Environment
Object
1000H
1001H
SDO
:
1600H
CANopen Device
Figure 3:デバイスモデル
CANopen デバイスには、上記のような共通したデバイスモデルのイメージが求められています。これによって、一
つの標準仕様でありながら様々なデバイスに対応できるよう考えられています。デバイスモデルは、大きく分けて以
下の三つ (左から) に分割されています。
4
•
通信
CAN メッセージ (通信オブジェクト言うことがあります) のタイミングを含めた送受信とそれらのハンドリング
を行います。ここでは、送受信されるデータオブジェクトにどのような情報が乗っているのかは全く意識され
ません。
•
Object Dictionary
通信部とアプリケーション部の橋渡しをするデータテーブル。情報の管理にインデックス番号を使うため、辞
書のような構造をもっています。たとえば、この CAN メッセージ (ID) はどんなデータがどのような順番で作
られているのか、設計図を含んでいます。
Object Dictionary にこのデバイス自体の CANopen デバイスとしての総ての情報が集められているので、
ここを変更 (コンフィギュレーション) することで自 CANopen ネットワークシステムの目的を達成することが
できるのです。
•
アプリケーション
デバイスプロファイルに決められた、または自社オリジナルのデバイスプロファイルのデータが羅列されま
す。ここは、プロセスデータとして他ノードとやり取りするデータのみがデバイスプロファイルに沿って格納さ
れます。ユーザーアプリケーションはこの羅列を参照/変更することになります。従って、CAN メッセージを意
識しません。
ネットワーク物理層
CANopen は、特定の環境でのフレキシビリティーを重視して、コネクター等の物理層について明確には規定してい
ません。工業分野向けには、仕様と推奨品が用意されています。
バスについては、ISO11898 に従った差動電圧で駆動するニ線式です。
“CiA DRP-303-1”では、D-sub 9 ピン (DIN41652 または国際規格に従ったもの) 、5 ピン、オープンスタイルとマル
チポールなど多数のコネクターのピンアサインが定義されています。
Application Note AN-JON-1-1100
5
Introduction to CANopen
5 Object Dictionary
CANopen の概念は、アプリケーションと通信を結びつける Object Dictionary を中心に考えられています。CAN バ
ス上に載せられるデバイスの全ての機能、変数とデータタイプは、Object Dictionary に記述される必要があります。
特徴は以下のようになります。
•
通信とアプリケーションを関連付けるパラメーターの集合
•
標準化された構造
•
配列、構造体形式を含む全てのデバイスパラメーターへのアクセス
•
データタイプの参照
Object Dictionary は、その名前のとおり単純は辞書のような構造をしています。各エントリーに 16 ビットのメインイ
ンデックスと 8 ビットのサブインデックスを持ち、これらによって各エントリーがアドレッシングされます。
インデックスは、メインインデックスが Object Dictionary 上のエントリーオフセットであり、これだけで構造を持たな
い “Boolean”や “Unsigned32”などのシンプルエントリーをアクセスすることができます。
メイン
インデックス
0x1000
エントリー
Device Type
データタイプ
Unsigned32
上記表の Device Type 情報は、プログラマからは以下のデータ構造として扱えると考えると判り易いでしょう。
unsigned long DeviceType;
構造体のような複数のデータを持つタイプの場合は、8 ビットのサブインデックスにより各メンバーと配列の各要素
を示すようになります。
メイン
インデックス
0x6092
サブ
インデックス
0
1
2
3
4
エントリー
エントリー数
Baud Rate
Number Of Data Bits
Number Of Stop Bits
Parity
データタイプ
Unsigned8
Unsigned16
Unsigned8
Unsigned8
Unsigned8
上記表の構造体データタイプは、プログラマからは以下のデータ構造として扱うことができます。
typedef struct {
unsigned char NumberOfEntries;
unsigned short BaudRate;
unsigned char NumberOfDataBits;
unsigned char NumberOfStopBits;
unsigned char Parity;
} RS232;
RS232 rs232;
Application Note AN-JON-1-1100
6
Introduction to CANopen
また、メインインデックスはオブジェクトの種類によっていくつかの領域に分けて配置します。詳細は、"DS-301:通
信プロファイル"に記述されています。
デバイス種類ごとの DS-4xx 番台のデバイスプロファイルは、メインインデックス 0x6000 番以降を定義したものと
なっています。
メインインデックス
オブジェクト
0x0000
0x0001-0x025F
0x0260-0x0FFF
0x1000-0x1FFF
0x2000-0x5FFF
0x6000-0x9FFF
0xA000-0xBFFF
0xC000-0xCFFF
not used
Data Types
Reserved for further use
Communication Profile Area
Manufacturer Specific Profile Area
Standardized Device Profile Area
Standardized Interface Profile Area
Reserved for further use
通信手法
6
CAN の規定では、ノードごとにアドレスを持つ考えではなく、バスに流れるメッセージの ID によって識別する"マル
チマスター方式"となります。CANopen では、各ノードにノード ID を持ち CAN のメッセージ ID にこのノード ID を関
連させて通信しています。
ノード間の通信メカニズムは、以下の送受信関係を基本しています。
•
クライアント/サーバー通信
ポイント to ポイント接続で、常にクライアント側から通信が開始される。複数のクライアント/サーバー通信が
確立可能。
•
マスター/スレーブ通信
ポイント to ポイント接続で、常にマスター側から通信が開始される。1 つのマスターデバイスに対して 1 個
~127 個のスレーブデバイスで構成される。
•
プロデューサー/コンシューマー通信
ブロードキャスト通信 (CAN 自体は元々ブロードキャスト通信)。
レスポンスを期待しない通信の場合プロデューサー側がイニシアティブを持ち、レスポンスを期待する通信
の場合コンシューマー側がイニシアティブを持つ。
Application Note AN-JON-1-1100
7
Introduction to CANopen
データ通信の通信オブジェクトは、PDO と SDO の二つがあります。それぞれの特徴は次のようになります。
プロセスデータオブジェクト:PDO
•
•
•
•
•
•
プライオリティーが高く、リアルタイム
データ転送が可能
ブロードキャスト通信
Ack (レスポンス) を必要としない
プロトコルによるオーバーヘッドがない
同期/非同期、周期/非周期、イベントド
リブン型通信
最大データ長は、8 バイト
サービスデータオブジェクト:SDO
•
•
•
•
•
Object Dictionary の読み書きに使用
ピア to ピア通信
Ack 待ちで通信正確性が高い
プライオリティーは低い
8 バイトを越えるデータの転送が可能
PDO は、CANopen ネットワークで交わされる通信の一番の目的である、一般のプロセスデータ転送に使われます。
SDO は、設定変更とデバイスの診断に使われます。PDO 程リアルタイム性は高くないが、大量のデータを扱える
柔軟性があります。
また、CANopen では、TimeStamp や SYNC といったリアルタイム通信に必要な通信オブジェクトも定義されてい
ます。
Application Note AN-JON-1-1100
8
Introduction to CANopen
7
ネットワークマネージメント
CANopen ネットワーク上のひとつのノードが NMT (Network Management) マスターとなり、その他の NMT ス
レーブノードの状態遷移をコントロールします。
NMT スレーブとなるデバイスは、それぞれが共通の状態
遷移をサポートする必要があります。
各デバイスの電源 ON と個別初期化処理後、NMT マス
ターが自動的に “Pre-operational” 状態に遷移させます。
この状態では、SDO による構成変更とパラメーター再設定
が可能 (通常コンフィグレーションツールから指示される)
で、PDO 通信はまだ許可されません。
NMT マ ス タ ー は 、 全 て の ノ ー ド ま た は 個 別 に
“Operational” 状態に遷移させることができますし、逆も同
様です。
Power ON
Hardware Reset
Initialize
Pre-Operational
Stopped
Operational
“Operational”状態で、PDO 通信が可能です。“Stopped”
状態になることでは、PDO および SDO は通信不可となり
ます。システム稼動中は、全通信オブジェクトがアクティブ
Figure 4 : NMT State Machine
な “Operational” となります。
NMT マスターとなるデバイスは、ネットワーク上の総ての NMT スレーブ (機能的なマスター/スレーブの関係とは
別です) を NMT 用の高プライオリティーコマンドで制御します。
CANopen プロトコルでは、状態遷移の他に、デ
heartbeat consumer
バイスの状態を監視するため“Heartbeat”と
heartbeat
heartbeat
“Guarding”の二つの手法を定義しています。
timeout
filter
evaluation
NMT マスターがスレーブに対して呼びかける
Guarding と自発的に自デバイスの状態を報告
する Heartbeat になります。
relevant
object dictionary entries
heartbeat producer
1026 consumer heartbeat time
cyclic
heartbeat
transmission
heartbeat consumer
heartbeat
filter
heartbeat
timeout
evaluation
relevant
object dictionary entries
1017 producer heartbeat time
CANopen デバイスは、両機能をサポートしてい
ても稼動時には一方のみで実行しなければなり
ません。最近のデバイスでは、Heartbeat をサ
ポートしているケースが多く見られます。
Hearbeat では常に自デバイスの状態を送信す
ることで、たとえば “電圧低下” などの状況をマ
スターからのポーリングなしに他のデバイスが
状態を把握することができます。“Emergency”
オブジェクト (オプション) によって、CANopen 共
通またはデバイスプロファイルで指定された共
通エラーコードを他のデバイスに通知する仕組
みも持ちます。
relevant
object dictionary entries
1026 consumer heartbeat time
Figure 5 : Heartbeat
Application Note AN-JON-1-1100
9
Introduction to CANopen
8
Pre-defined コネクションセット
クライアント = サーバー間、プロデューサー = コンシューマー間の全てのコネクションは、Object Dictionary 上の設
定でダイナミックに設定が可能です。DeviceNet にある、オブジェクト間の動的なコネクションのオープン/クローズと
言った考えはありません。
1 つの CANopen ネットワークに複数の機能を実現するためのデバイス間のコネクションがある場合 (ある機能を実
現するためのマスター/スレーブの関係) 、これらの関係を一から定義するのは非常に手間がかかりますが、予め決
められた“Pre-defined コネクションセット”の設定ルールに従うことで、デバイス間のコンフィギュレーションを容易に
行なうことができます。
“Pre-defined コネクションセット”は、デバイスのノード ID をキーとした仕組みであるので、これをデフォルトでインプ
リメントしているデバイスであれば、倉庫から出して来てノード ID (他のデバイスと重なってはいけない) の設定を行
なうだけで、通信が開始できるわけです。
Application Master
Device 1 with Slave
functionality
Device 2 with Slave
functionality
:
Device 127 with Slave
functionality
Figure 6:Pre-defined コネクションセットの概念図
Application Note AN-JON-1-1100
10
Introduction to CANopen
9
CANopen システムのコンフィグレーション
CANopen では、ネットワークシステムのコンフィグレーションの方法についても推奨しています。
デバイスには、デバイス自体のプロファイル情報として EDS ファイルを作成する必要があり、これにはそのデバイ
スがサポートしている機能を Object Dictionary のエントリー形式で記述されます。
CANopen ネットワークシステムのコンフィグレーションでは、各デバイスの EDS ファイルを基に具体的な設定値を
決めた DCF:Device Configuration File を作成し、この内容を実デバイスの Object Dictionary に書き込むことで
設定変更を行ないます。 ここでの設定の参照と変更に SDO 通信が使われます。一般的に CANopen 専用のコン
フィグレーション用アプリケーションソフトで一連の操作を行なうことができます。
CANopen Device
provided by
module supplier
Object Dictionary
supplied to
configuration system
EDS
(electronic data sheet)
distribution of
configured
information
created by configuration tool
DCF
(device configuration files)
Figure 7:CANopen ネットワークシステムのコンフィグレーション
Application Note AN-JON-1-1100
11
Introduction to CANopen
デバイスプロファイル
10
CANopen では、通信プロトコルとデバイス種類ごとのプロファイルを別に定義しています。デバイスプロファイルに
は、その種類のデバイスに必要な基本機能が定義されており、これによってデバイスアクセスの標準化を実現して
いるわけです。
具体的には、以下の内容が定義されています。
•
デバイス基本機能の定義
Î
•
Pre-defined コネクションオブジェクトの選択肢を提供
Î
•
ネットワークコンフィグレーションが容易
Object Dictionary 内にデバイスベンダー用プロファイル領域を確保
Î
•
ドライブのコマンドや I/O のフィルタなど、基本機能の置き換え
デバイスの状態遷移の統一
Î
•
デバイス基本機能へのアクセスを標準化
例:I/O デバイスの入出力方向設定、ドライブの ”停止” 命令
ベンダー固有機能が定義可能
共通エラー条件/状態を定義
DS-301:通信プロファイルで定義されたエラー情報をデバイスの種類ごとに拡張可能
Application Note AN-JON-1-1100
12
Introduction to CANopen
11
最後に
CANopen は、CAN を物理層に持つ分散制御ネットワークの通信に必要な機能を提供しているものです。
プロトコル仕様が公開されたオープンネットワークとして、仕様をまとめている CiA が提供するコンフォーマンステス
トツールにより、プロトコルが正しくインプリメントされているかチェックでき、逆にコンフォーマンステストにより
CANopen 適合とされたデバイスは、他の適合済みデバイスと CANopen ネットワークを容易に構成することが可
能と言えます。
デバイスメーカーにとってみれば、たとえば従来の DeviceNet デバイスをハードウェアにほぼそのままファームウェ
アを改造することで CANopen 対応とすることができ、CANopen の主要市場であるヨーロッパへの展開が考えられ
るでしょう。
一方、これまで独自のピア・ツー・ピアによる通信を採用していた機械メーカーにとっては、CAN/CANopen を採用
することでノイズに強いバス形式の通信を実績のあるプロトコルで、しかもコンフォーマンステストに合格したデバイ
スを世界中から選び、組み合わせて望みのシステムを構築することができるわけです。
FA や分散制御ネットワークのための標準通信プロトコルとして普及しているので、デバイス開発のためのツールお
よび組込ソースコード、ネットワーク運用のためのコンフィグレーションおよび運用監視ツールが、多数揃っているこ
とも特徴です。
具体的な CANopen 応用事例としては、工作機械 (射出成形、個装、製缶など) 、医療器械 (レントゲンシステム) 、
鉄道車両、セキュリティー (ビル管理) などが挙げられる。中には、業務用のコーヒーマシンに使われている例もあり
ます。
まずは、CANopen 仕様の策定元であるCiA:CAN in Automation (http://www.can-cia.de/の Web ページ) にアク
セスしてみる事を勧めします。
12
連絡先
ベクター・ジャパン株式会社
(東京本社)
〒140-0002 東京都品川区東品川 2-2-20 天王洲郵船ビル 16F
(名古屋支社)
〒460-0008 愛知県名古屋市中区栄 4-5-3 KDX 名古屋栄ビル 9F
URL: http://www.vector-japan.co.jp
■ 営業部
(東京) TEL: 03-5769-6980
(名古屋) TEL: 052-238-5020
E-mail: sales@jp.vector.com
FAX: 03-5769-6975
FAX: 052-238-5077
■オープンネットワーク部
(東京) TEL: 03-5769-6974
E-mail: CANopen@jp.vector.com
Application Note AN-JON-1-1100
13