CANopenプロトコル

CANopenプロトコルの紹介

CANopenはCANベースの通信システムです。上位層プロトコルとプロファイル仕様で構成され、非常に柔軟な構成機能を備えた標準化された組み込みネットワークとして開発されました。当初はハンドリングシステムなどのモーション指向の機械制御システム向けに設計されました。現在では、医療機器、オフロード車両、船舶用電子機器、鉄道アプリケーション、ビルオートメーションなど、様々なアプリケーション分野で使用されています。

OSI通信システムモデルにおいて、CANは最初の2つのレベル、すなわち物理層とデータリンク層をカバーします。CANopenは、ネットワーク（アドレス指定、ルーティング）、トランスポート（エンドツーエンドの信頼性）、セッション（同期）、プレゼンテーション（標準的な方法でエンコードされたデータ、データ表現）、アプリケーションという上位5つの層（図1）をカバーします。アプリケーション層は、CANopenデバイスの設定、転送、および同期の方法を記述します。

CANopen オブジェクトディクショナリ

CANopenの中心的なテーマの一つはオブジェクトディクショナリ（OD）です。これは基本的に、設定とプロセスデータを格納するテーブルです。すべてのCANopenデバイスは、オブジェクトディクショナリを実装する必要があります。CANopen規格では、16ビットのビットインデックスと8ビットのサブインデックスが定義されています。規格では、特定のアドレスとアドレス範囲に特定のパラメータを含める必要があると定義されています。例えば、インデックス1008h、サブインデックス00hにはデバイス名を含める必要があると定義されています。そのため、CANopenマスターはCANopenスレーブネットワークからこのインデックスを読み取ることで、各スレーブを名前で一意に識別できます。デバイスタイプ（1000h）など、一部のオブジェクトディクショナリインデックスは必須ですが、メーカーのソフトウェアバージョン（100Ah）など、その他のインデックスはオプションです。

オブジェクトディクショナリは、CANopenデバイスと通信するための手段です。例えば、オブジェクトディクショナリのメーカー固有セクション（2000h～5FFFh）のインデックスにTrueを書き込むと、デバイスはこれを電圧入力からデータを取得するためのイネーブル信号として解釈します。逆に、マスターはオブジェクトディクショナリから情報を読み取って取得したデータを取得したり、デバイスの現在の設定を確認したりすることもできます。オブジェクトディクショナリにアクセスするための2つの通信メカニズムは、サービスデータオブジェクト（SDO）とプロセスデータオブジェクト（PDO）です。これらについては、このドキュメントの後半で説明します。

オブジェクトディクショナリの構造は、 図2.

CANopenメッセージフォーマット

CANopenフレームのメッセージフォーマットは、CANフレームフォーマットに基づいています。CANプロトコルでは、データは11ビットまたは29ビットのCAN-ID、リモート転送ビット（RTR）、スタートビット、4ビットのデータ長フィールドなどの制御ビット、そして0～8バイトのデータで構成されるフレームで転送されます。CANopenで一般的にCOB-IDと呼ばれるものは、CAN-IDと制御ビットで構成されています。CANopenでは、11ビットのCAN IDは4ビットの機能コードと7ビットのCANopenノードIDの2つの部分に分割されています。7ビットのサイズ制限により、CANopenネットワーク上のデバイスの数は127ノードに制限されます。

CANopenプロトコル

SDO（サービスデータオブジェクト）プロトコル

CANopenプロトコルでは、ネットワーク上の各ノードがオブジェクトディクショナリへの読み取り/書き込み要求を処理するサーバーを実装する必要があることも規定されています。これにより、CANopenマスターはサーバーのクライアントとして動作できます。サーバーのオブジェクトディクショナリへの直接アクセス（読み取り/書き込み）のメカニズムは、サービスデータオブジェクト（SDO）です。オブジェクトディクショナリへのアクセスを受けるノードはSDOサーバー、データを取得するノードはSDOクライアントと呼ばれます。転送は常にSDOクライアントによって開始されます。

PDO（プロセスデータオブジェクト）プロトコル

プロセスデータは、ノードコントローラの入力（センサーなど）や出力（モータードライブなど）など、時間の経過とともに変化する可能性のあるデータを表します。プロセスデータはオブジェクトディクショナリにも保存されます。しかし、SDO通信では一度に1つのオブジェクトディクショナリインデックスにしかアクセスできないため、継続的に変化するデータへのアクセスには大きなオーバーヘッドが発生する可能性があります。さらに、CANopenプロトコルでは、ノードがCANopenマスターからのポーリングを必要とせずに、独自のデータを送信できる必要があります。そのため、プロセスデータの転送には、プロセスデータオブジェクト（PDO）と呼ばれる通信方式という別の方法が使用されます。

PDOには、転送PDO（TPDO）と受信PDO（RPDO）の2種類があります。TPDOはノードから送信されるデータ（生成データ）であり、RPDOはノードに送信されるデータ（消費データ）です。さらに、PDOには構成パラメータとマッピングパラメータの2種類のパラメータがあります。PDOの構成情報とマッピング情報用に予約されているオブジェクトディクショナリのセクションは、インデックス1400h～1BFFhです。

設定パラメータは、COB-ID、伝送タイプ、インヒビット時間（TPDOのみ）、イベントタイマーを指定します。これらについては、このセクションで説明します。PDO転送を開始するには、イベント駆動型、時間駆動型、個別ポーリング、同期ポーリングなど、様々な方法があります。伝送の種類は、PDOの設定パラメータで指定します。イベント駆動型伝送では、PDO転送はプロセスデータの変化時に開始されます。時間駆動型伝送では、PDO転送は一定の時間間隔で行われます。個別ポーリングでは、PDO転送はリモートリクエストと呼ばれるメカニズムを使用して開始されますが、これはあまり一般的には使用されません。同期ポーリングでは、PDO転送はSYNC信号を使用して開始されます。同期信号は、グローバルタイマーとしてよく使用されます。例えば、CANopenマスターがSYNCメッセージを送信した場合、複数のノードがそのSYNCメッセージを受信して応答するように設定できます。このようにして、マスターは複数のプロセスオブジェクトの「スナップショット」を同時に取得できます。

NMT（ネットワーク管理）プロトコル

ネットワーク管理サービスには、スレーブの状態を初期化中、動作前、動作中、停止の間で変更する機能が含まれます。NMTプロトコルにより、CANopenネットワークは個々のノードの通信状態を制御できます。動作前状態は主にCANopenデバイスの設定に使用されます。そのため、PDO通信は動作前状態では許可されておらず、動作状態でのみ可能になります。停止状態では、ノードはノードガーディングまたはハートビートのみを実行でき、メッセージの送受信はできません。特定の種類のCANopen通信は、異なる状態で許可されます。例えば、SDOは動作前状態で許可されますが、PDOは許可されません。

これは、SDO はオブジェクト ディクショナリ パラメータを初期化するために使用されることが多いのに対し、PDO は継続的に更新されるデータを転送するために使用されることが多いためです。

特殊機能プロトコル

エラー制御プロトコル

エラー制御プロトコルは、CANopenネットワークの監視を可能にします。これらのプロトコルは、ハートビートプロトコル、ノード/ライフガーディングプロトコル、そしてブートアッププロトコルで構成されています。ハートビートプロトコルは、CANopenネットワーク内のすべてのネットワーク参加者が引き続き利用可能であり、意図されたNMT FSA状態にあることを確認するために使用されます。旧式のCANopenシステムでは、この目的のためにハートビートプロトコルではなく、CANリモートフレームベースのノード/ライフガーディングプロトコルが使用されています。CAN in Automationでは、CANリモートフレームベースのサービスの使用は推奨されていません。

ハートビートプロトコルは、すべてのハートビートコンシューマにハートビートプロデューサの可用性を通知する、周期的に送信されるメッセージです。ハートビートプロデューサの可用性に加えて、ハートビートプロトコルは、ハートビートプロデューサの現在のNMT FSA状態も提供します。

ブートアッププロトコルは、特殊なタイプのエラー制御プロトコルです。NMT FSAの初期化状態における最終アクションとして送信され、NMT FSAがPre-operational状態に入る前に送信されます。このメッセージの受信は、新しいデバイスがCANopenネットワークに登録されたことを示します。

ガーディングは、ガードされたCANopenデバイスが正しいネットワーク状態で動作しているかどうかを確認するための時代遅れの方法です。これはRTRベースのサービスであるため、新しい設計ではハートビートプロトコルが使用されます。

Typhoon HILツールチェーンにおけるCANopenの実装

CANopen は、Typhoon HIL デバイス ( HIL101、HIL404、HIL602+、HIL604、HIL506、HIL606)でサポートされています。

現在サポートされている各HILデバイスには、それぞれ独立したコネクタを備えた2つのCANコントローラが搭載されており、100MHzのリファレンスクロックで動作します。これらの2つのコントローラ（CAN1およびCAN2）は、以下のピン配列を持つ標準9ピンD-subタイプ（オス）コネクタを介してCANネットワークに接続できます。

CANコントローラは抵抗で終端されていません。必要に応じて120Ωの終端抵抗を追加できます。

現在、CANopen Slave のみが実装されています。CANopen Slave は信号処理コンポーネントとして実装されており、 Communication/CAN/CANopen/CANopen Slaveにあります。

CANopenスレーブ

CANopen スレーブ コンポーネントは、.eds または .dcf ファイルをインポートすることによってのみ構成できます。

CANopen スレーブ コンポーネントは表 1に示され、CANopen ダイアログ ウィンドウは図 5に示されます。

表1 . CANopenスレーブ

成分	コンポーネントのプロパティ
CANopenスレーブ	EDSまたはDCFファイルをインポートする
	CANコントローラ
	ボーレート
	スレーブID
	実行率

デバイス構成

設定を選択すると、ボーレートコンボボックスとスレーブIDの値に設定値が表示されます。ダイアログウィンドウのデバイス設定部分には、スレーブデバイスのオブジェクトディレクトリ（OD）を表すテーブルが表示されます。これは図6に示されています。

ファイル情報タブとデバイス情報タブには、ファイルから解析された基本情報のみが表示されます。これらのフィールドの内容は図7に示されています。

オブジェクトディクショナリタブ

オブジェクト ディクショナリ タブの外観を図 8に示します。

サブインデックス、名前、タイプ、アクセス、値は設定ファイルから直接解析されます。値フィールドはさらに詳細に定義できます。

モデル制御列は、特定の辞書オブジェクトの値をモデルからの信号で制御するかどうかを定義します。このフィールドを有効にすると、コンポーネント上に端子が作成され、任意の信号処理信号をそのオブジェクトに接続できるようになります。端子の方向は端子タイプフィールドで定義します。モデル制御フィールドは、0x2000～0x9FFFの範囲の辞書オブジェクトでのみ使用できます。

設定ファイルを解析する際に、一部のターミナルタイプ値が自動的に定義されます。オブジェクトが受信PDOマッピングにある場合、ターミナルタイプはoutとして定義されます。オブジェクトが送信PDOマッピングにある場合、ターミナルタイプはinとして定義されます。

接続例

オブジェクト ディクショナリ フィールドが定義されると、図 9に示すように、コンポーネントに端子が作成され、モデルの適切な信号処理信号を接続できるようになります。

モデル制御が有効になっているディレクトリオブジェクトごとに、コンポーネント上にターミナルが作成されます。スレーブステートマシンの状態を監視するために、slave_stateという追加のターミナルが自動的に作成されます。

仮想HILサポート

Virtual HILは現在このプロトコルをサポートしていません。非リアルタイム環境（例：ローカルコンピュータでモデルを実行する場合）を使用する場合、このコンポーネントへの入力は破棄され、このコンポーネントからの出力はゼロになります。