CANopen規格では、“各デバイス内のオブジェクトディクショナリーの情報をシステム要件に応じて適切に書き換えること”をコンフィギュレーションといいます。具体的には、各デバイスのEDSファイルをコンフィギュレーションツールなどで読み込み、各オブジェクトディクショナリーのエントリに必要な設定を施して、それぞれの「DCF(Device Configuration File)」を作成し、各デバイスにダウンロードする(オブジェクトディクショナリーの情報を上書きする)という手順になります。
デバイスベンダからは、それぞれ自社のデバイスをコンフィギュレーションする専用ツールが提供されていますので、それらのツールを使ってデバイスを個々にコンフィギュレーションできます。
なお、システム内に複数のベンダのデバイスを使う場合、それらの専用コンフィギュレーションツールも複数になってしまいますので、汎用的なコンフィギュレーションツールを使うと便利です。汎用コンフィギュレーションツールは、CANopen準拠のデバイスであれば、異なるベンダのデバイスが混在するネットワークでも、すべてのデバイスを一括でコンフィギュレーションできます。もちろん市販デバイスだけでなく、自作デバイスも併せてコンフィギュレーション可能です。
CANopenシミュレータがあれば、実機がまったくない段階でも、ネットワークの通信負荷や各デバイスの送受信周期や応答時間などを検証できます。
この時点でネットワーク上のデバイスはすべて仮想デバイスでも構いませんし、もしいくつかの市販デバイスや試作デバイスがあれば、それらの実デバイスとシミュレータ上の仮想デバイスを混在させて通信シミュレーションさせることも可能です。
このような環境があれば、システム規模やネットワーク仕様、デバイス個々の仕様などを短期間で効率よく設計できます。ネットワーク設計の初期段階で綿密なシミュレーションを行うことにより、開発や運用など後の工程における不測の問題発生や手戻りを減らし、全体の工数削減につながります。
また、先述したCANoe.CANopenは、「MATLAB/Simulink」などを併用したモデルシミュレーションも可能です。ほかのWindowsアプリケーションと相互にアクセスしたり、別売りのハードウェアを追加してデジタルやアナログのI/Oにアクセスしたりできるので、実際のネットワークに近いシミュレーション環境が構築できます。
CANopenネットワークには、原則としてネットワークマネジメントマスターの機能を持ったデバイスが1つ必要です。CANopenのネットワークマネジメントは、運用時にシステム構成が変わる動的な仕様の場合には高度な機能が必要になりますが、あらかじめ決められた静的な仕様で運用される場合には、非常に簡単な機能で済む場合もあります。
例えば、ネットワーク上のデバイス構成があらかじめ決まっていて、運用時にユーザーやインテグレータがシステム構成やデバイス設定を変える必要がない場合は比較的簡単です。そのような場合、システム構築時に各デバイスの不揮発性メモリにそれぞれのコンフィギュレーションを格納しておけば、起動時やリセット時にネットワークマネジメントマスターがスタート/ストップなどのコマンドメッセージを送信するだけでシステムを運用できます。
一方で、システム規模や動作モードなどの条件によってネットワーク全体の通信速度や各デバイスの設定、デバイス同士の通信関係が変わる場合は、システム起動時や運用開始時に各デバイスのコンフィギュレーションが必要です。例えば、あらかじめ想定されるパターンに応じて各デバイスのDCFを格納しておき、必要に応じてそれらを読み込んでコンフィギュレーションする方法もあります。また、システム運用者がその都度プログラムや設定を行い、各デバイスをコンフィギュレーションする方法もあります。
いずれの場合も、マイコンに組み込み実装したり、CANopen対応PLC(Programmable Logic Controller)でプログラムしたりできます。また、Windows PCがあるシステムであれば、前述のProCANopenなどのアプリケーションソフトウェアでもコンフィギュレーションできます。最終的なシステム構成に応じて、これらの運用方法や実装方法を任意に選択できることもCANopenの特徴の1つです。
新規デバイスを開発する場合、CANopenプロトコルの実装はハードウェアによる方法とソフトウェアによる方法の大きく2つに分けられます。
ハードウェアによる実装は、CANopenのネットワークマネジメントマスターやスレーブなどの機能を実装したチップ(ASIC)を利用する方法が挙げられます。この方法は、チップの仕様によって使える機能やコンフィギュレーションの範囲が限定されますが、必要な機能さえ満たしていれば、プロトコル部分のソフトウェア開発工数を抑えられます。チップ単価や基板の物理的な実装レイアウトなどハードウェア的な要件に問題がなければ、試作開発や少量の初期ロットなどに有効な方法です。
一方、アプリケーションも含めて汎用マイコンでワンチップ化したい場合には、CANopenプロトコルの組み込みソフトウェアを購入して、実装する方法が挙げられます。この方法は、CANopenのプロトコルスタックがオブジェクト化されたライブラリで提供される場合、前述のチップ実装と同様に、使える機能やコンフィギュレーションの範囲が限定される場合があります。
また、ソースコードでCANopenプロトコルスタックが提供される製品もあります。その場合には、実装する機能の選択や各機能の詳細な設定まで任意にカスタマイズできます。連載第2回で紹介したように、CANopenには「デバイスプロファイル」や「アプリケーションプロファイル」と呼ばれるさまざまな制御仕様が標準化されており、メーカー独自の制御プロファイルも開発して実装できます。このような上位のプロファイルも含めて実装したい場合には、ソースコード形態で提供される方が設計開発に融通が利きます。
なお、チップ実装とソフトウェア実装にはそれぞれ異なる利点があります。試作や初期ロットではチップによる実装を用いて、大量生産ロットで汎用マイコンによる実装を行うなど、異なる方法の段階的な採用や併用によってコストやリスクをコントロールする例も挙げられます。
今回紹介した8つの工程は、あくまで一例です。CANopenネットワークはシステム構築の自由度が高く、デバイス個々にも高い汎用性がありますので、設計開発のフローや必要なツールも要件によって異なります。現在検討中のシステムにCANopenが適しているのか、CANopenを使うとしたらどこからはじめればよいのかなどの質問・疑問は、デバイスベンダやCiAマーケティンググループジャパンにお問い合わせください。
Copyright © ITmedia, Inc. All Rights Reserved.