　CANopenの中心となる通信プロトコル部分は、OSI（Open Systems Interconnection：開放型システム間相互接続）参照モデルでいうところのアプリケーション層に相当します。物理層とデータリンク層には、CAN（Controller Area Network）を用います（図1）。CANが伝送媒体の電気的特性やメッセージ（パケット）伝搬のルールを定めた“メディア”の規格だとすれば、CANopenはそのメディアをどのようなルールで使いこなすかを定めた“ハウツー”になります。CANopenそのものはそれだけではなく、デバイスの種類やアプリケーションごとにハウツーを使いこなす詳細な定義（プロファイル）も含まれています。プロファイルについては、連載第2回以降で紹介します。

図1　OSI参照モデルにおけるCANとCANopenの定義範囲

オープンネットワークとは？

　オープンネットワークを直訳的に説明すると、

公開されている規格（オープンプロトコル）に準拠したデバイスを使って構築したネットワーク

といえます。公開された同じ規格に準拠したデバイスであれば、異なるメーカーのデバイス同士でも自由な相互接続やシステム構築が可能です。

　身近な例としては、PCおよび周辺機器の接続に使われる通信ネットワークも広義のオープンネットワークといえます。公開された標準規格に準拠していれば、PCや周辺機器のメーカーに依存せずに、デザインや機能、価格などを判断基準にしてユーザーが任意の機器を選択して使用できます。

　本連載の主役CANopenが使用されている産業分野でもこれと同じことがいえます。装置メーカーやシステムインテグレータ、つまりデバイスユーザーは、市場で提供されているCANopen対応デバイスの中から、要求仕様に応じて適切な価格や性能を持つデバイスを選択して、車両や装置のシステムを構築できます。

　一方でデバイスメーカーは、自社デバイスをCANopen規格に準拠させることにより、汎用デバイスとして広い市場に販売できます。誰もが自由に規格書を入手でき、その規格に対応した製品を開発、販売、使用できるので、市場参入や市場競争もオープンであるといえます。CANopenは規格の名前が示すとおり、CANを利用したオープンネットワークの代表例です。

CANの普及

　CANは、自動車のECU（Electronic Control Unit：電子制御装置）のネットワーク制御のために開発された通信規格です。ISO（International Organization for Standardization：国際標準化機構） 11898として国際規格化され、世界中の自動車メーカーが車両ネットワークの制御に使用しています。

　CANは開発の当初、“車載LAN”という印象が強かったため、しばしば“Car Area Network”と間違われますが、正しくは“Controller Area Network”です。CANは自動車のエンジン制御にも使われているだけあって、非常に高い通信の信頼性を誇ります。また自動車産業における普及に伴い、CANコントローラを内蔵した汎用マイコンが広いラインアップで提供されているため、現在は自動車だけでなくさまざまな産業分野の組み込みネットワークで使用されています。

　各産業分野には、CAN以外にも普及しているオープンな通信プロトコルがあります。しかし、公開された規格であっても、特定メーカーの専用チップが必要になったり、生産や販売の数量に応じてロイヤルティーライセンス費用が必要になったりする場合もあります。

　CANも、厳密には独ロバート・ボッシュ社へのライセンス費用が生じますが、CANコントローラ内蔵マイコンの場合、マイコンメーカーがライセンス費用を払ってCANコントローラを実装しています。つまり、マイコンの価格にCANのライセンス費用も含まれているので、マイコンユーザーに対して別途CANのライセンス費用を請求されることはありません。

　今日では多くのマイコンメーカーが8bit、16bit、32bitのマイコンにCANコントローラを内蔵しており、ハードウェアプラットフォームの選択肢の広さや供給の安定性も、CANがさまざまな産業分野に普及している理由の1つといえます。

CANの上位層プロトコル

　CANの送受信単位であるCANメッセージには、11bitまたは29bitのIDフィールドと、64bitのデータフィールドが含まれ、そのIDやデータはユーザーが任意に設定できます。例えば、ID＝0にはXのコマンド、ID＝1にはYのコマンド、ID＝100にはAのデータ、ID＝200にはBのデータ、などです。

　いい換えると、CANはあくまでも物理層とデータリンク層で“メディア”の型や送受信方法を定めた規格であり、固有のアプリケーションや制御に相当する“ハウツー”までは定義していません。つまり、CANメッセージのIDの採番やデータの規則およびそれらの応答は、すべてCANよりも上位のプロトコルとして設計開発する必要があるのです。

　これは、ネットワーク上のデバイスの数や種類が少なく、複雑な制御を必要としなければ大きな問題にはならないでしょう。しかし、システムの規模が大きくなり、デバイス数の増加、制御の複雑化に伴って、制御の“ハウツー”も複雑になります。

　例えば、デバイスを識別するためのデバイス固有IDの割り付け、デバイスの起動／停止／待機などの状態遷移制御、動作時の継続的なアライブチェック、緊急事態を知らせるエマージェンシーメッセージとその対応、マスター異常の検出とその対応など、システム設計者はこれらの仕様設計に頭を悩ませ、試作や試験を繰り返して多くの時間を費やすこともあると思います。

　CANopen規格では、そのようなネットワーク管理の方法をはじめ、I/Oやモーションコントローラなどの汎用デバイスの制御プロファイルも定められており、それらをシステム個々の要件に応じて任意にコンフィギュレーションできます。つまり、一般的なネットワーク管理やデバイス制御、データ伝送などの“非競争領域”の仕様が規格化されているので、CANopenを使用することで、“競争領域”であるユーザー独自のアプリケーション開発に専念できます。

　　　　　　 1|2 次のページへ