Modbusの概要

Modbusの概要

Modbusは、デバイス間のSCADA（リモート監視・制御システム）スタイルのネットワーク通信でよく使用されます。 たとえば、プログラマブルロジックコントローラ（PLC）またはプログラマブルオートメーションコントローラ（PAC）のマスタには、大型サーバを使用し、 PLC/PACがセンサ、バルブ、モータ、その他の組込デバイスをマスタします。

Modbusは、これらのニーズに応えるために、柔軟なデータ/機能モデルを採用した要求/応答モデルとして設計されています。この機能が、現在でも引き続き使用されている理由の一部です。

Modbusプロトコルは、マスタ/スレーブアーキテクチャを採用しており、マスタがスレーブに要求を送信して、応答を待ちます。 このアーキテクチャは、情報の流れをマスタが完全に制御できるので、旧式の分岐シリアルネットワークにとって有益です。 現代のTCP/IPネットワークでも、マスタがスレーブ動作の多くを制御できるため、一部のデザインでは便利です。

図1. Modbusデバイスのマスタ/スレーブ、要求/応答の関係

Modbusでは、この要求は、階層化されたデータセットです。 最初のレイヤは、アプリケーションデータユニット（ADU）です。これは、使用するModbusのタイプともいえます。 ASCII、リモート端末装置（RTU）、TCP/IPの3つのADUがあります。

TCPは、要求ごとに専用の接続とIDを使用してネットワーク処理を効率化するとともに、Modbus要求/応答をソフトウェアで効率的に処理できる現代的なフォーマットです。 RTUとASCIIは、旧式のシリアルADU形式で、2つの違いは、RTUがコンパクトなバイナリ表記を使用するのに対して、ASCIIはすべての要求をASCII文字のストリームとして送信します。

ほとんどのアプリケーションで、どのADUが推奨されるかは、目的の物理ネットワーク（Ethernet、シリアル、その他）、ネットワーク上のデバイス数、ネットワーク上でマスタおよびスレーブデバイスがサポートするADUの数に依存します。 Modbusを使用するアプリケーションから見たとき、データは、あたかもADUが存在しないように見える必要があります。

各ADU内には、Modbusプロトコルの中心であるプロトコルデータユニット（PDU）があります。 各PDUには、関数コードと関連データが含まれています。 各関数コードには、応答を適切に定義します。この関数コードは、スレーブに送信されるコマンドといえます。

エラーが発生する場合があります。 Modbusでは、例外用に特定のPDUが定義されており、これは何が起きたかをマスタに知らせます。 ほとんどのドライバは、これを使用中の言語またはアプリケーション用が理解できる形式に変換します。

Modbusは、データのアクセスを単純かつ柔軟に管理します。 Modbusは、ブール値と符号なし16ビット整数の2つのデータタイプをネイティブにサポートします。

SCADAシステムでは、組込デバイスでゲイン、PID（比例、積分、積分）などの値を入力として定義し、また、現在の温度やバルブ位置などの値を出力として定義することがよくあります。 このニーズに応えるために、Modbusデータ値は、4つの範囲に分割されています（表1を参照）。 スレーブでは、範囲あたり最大65,536個の要素を定義できます。

表1. Modbusデータモデルブロック

多くの場合、センサやその他のデバイスは、単純なブールや符号なし整数以外のタイプのデータを生成します。 一般的に、スレーブデバイスはこれらの大きなデータタイプをレジスタに変換します。 たとえば、圧力センサは、32ビット浮動小数点数値を2つの16ビットレジスタに分割する場合があります。

Modbusは、これらの値を完全に概念的な方法で露出するため、実際にはメモリに存在しない場合があります。 たとえば、スレーブで保持レジスタと入力レジスタが同じメモリを共有することが合理的な場合は、そのように定義することができます。 ほとんどの場合、スレーブは、サポートするデータタイプごとに別々のメモリに格納し、マスタがアクセスできるデータ要素数を制限します。 この柔軟性は、Modbus機能の詳しく定義された動作を通じてデータが露出される方法が理由でオプションです。

Modbus機能コードは、マスタがデータにアクセスする方法およびデータを変更する方法を定義します。 データ範囲が概念的であるのとは異なり、機能コードは動作が詳しく定義されています。 スレーブは、機能コードの実行を依頼されると、機能のパラメータを使用して、詳しく定義された動作を実行します。 図2は、機能要求とデバイスの実際のメモリとのリンクを示しています。

図2. 機能コード、データ範囲、スレーブデバイスの実際のメモリの間のマッピング

ほとんどの一般的な機能コードは、変更またはアクセスする概念的なデータ範囲に従って名前が付けられています。 たとえば、「Read Holding Registers（保持レジスタの読み取り）」は、保持レジスタとして定義されているメモリからデータを読み取り、マスタに返します。 表2は、一般的な機能コードを表しています。

表2. 一般的な機能コード

LabVIEWでModbusを使用する

Modbusデバイスと通信する方法は、(1) 高レベルOPCサーバ (2) Modbus I/Oサーバ (3) NI LabVIEW 2014で追加された、LabVIEW Real-TimeまたはLabVIEW Datalogging and Supervisory Control（DSC）経由の低レベルModbus API

Modbus要求のシーケンシングとタイミングに関してアプリケーションで、高レベルの制御が必要な場合は、低レベルModbus APIをお勧めします。 また、柔軟性が非常に重要な場合も、低レベルAPIをお勧めします。 LabVIEW Modbus APIにより柔軟性とパワー得られる反面、APIを正しく管理するためにアプリケーションコードが複雑にならざるをえません。 この複雑性の理解を助けるために、LabVIEWに2つのサンプルが含まれています。

Modbusの最初の例

最初のサンプル（Modbus Library.lvproj）は、APIの基本機能を紹介するものです。 また、PCでの実装とリアルタイムターゲットでの実装の違いも紹介しています。 図3は、Real-Time Modbus Masterサンプルを表しています。

図3. Master on RT Target.vi

このサンプルは、LabVIEW APIを使用するModbusアプリケーションの中心的要件を表しています。 まず、Modbusインスタンスを作成します。 ここでは、TCPマスタです。 これは、多態性インスタンスセレクタでシリアルマスタに変更することにより、切り替えられます。

図4. Modbusマスタのタイプの変更

インスタンスを作成すると、スレーブデバイスにデータのポーリングを開始できます。 ここでは、機能コードRead Input Registersを使用します。 APIでサポートされるすべてのModbus機能コードは、適切なパレットに表示されます。 スレーブAPIには、プロトコルの実装が理由で、マスタでは実装できない追加機能があります。 たとえば、スレーブは、入力レジスタ範囲に書き込めますが、マスタは範囲から読み取ることしかできません。 図5は、機能コードを表しています。

図5. 機能コードを表示しているModbusマスタおよびスレーブパレット

最後に、Modbusインスタンスを閉じます。これにより、インスタンスに関連付けられているメモリが解放されます。 また、これにより、インスタンスが使用していたTCP接続またはNI-VISAシリアルリファレンスなどのリファレンスも閉じられます。

ここまで、マスタのサンプルだけを紹介してきましたが、すべてのサンプルは、「開く、読み取り/書き込み、閉じる」というLabVIEWで定型的な基本パターンに従っています。

最後に、APIの外観は同じでも、重要な違いを理解しておく必要があります。 デバイスがマスタであれば、データを集録するために適切なスレーブにネットワーク経由で要求を送信する必要があります。 これに対して、スレーブは自分のデータストレージがあるので、データに素早くアクセスできます。

冗長化マスタの例

一部のアプリケーションには基本サンプルで十分ですが、センサやゲートウェイと通信するという複雑なアプリケーションには不十分な場合があります。 このギャップを埋めるために、サンプルアプリケーションで、2つのマスタを使用してスレーブと通信する方法を紹介します。 1つのマスタに障害が発生し、スレーブまたはHMI（ヒューマンマシンインタフェース）との接続が失われた場合、もう1つのマスタが処理を実行します。

図6. 冗長化マスタの設計例

この設計があなたのアプリケーションのニーズに一致しているか、これより複雑なModbus通信について知りたい場合は、サンプルファインダでRedundant Modbus Masters.lvprojを参照してください。

LabVIEW DSCおよびLabVIEW Real-Timeモジュールに含まれているModbus I/Oサーバは、Modbus経由で通信する高レベルエンジンを提供します。 送信する機能コードを指定するのではなく、アクセスしたいデータセットを登録しておくことで、指定頻度でI/Oサーバが自動的に要求をスケジューリングします。

I/Oサーバを使用するには、プロジェクトで目的のターゲットに新しくI/Oサーバを追加します。 低レベルAPIと同様、Modbusマスタまたはスレーブを選択でき、それに応じて追加パラメータが表示されます。 たとえば、マスタでは、ポーリングレートを定義します。ポーリングレートとは、スレーブにすべての要求が送信される頻度です。スレーブはそれらの要求を待つ側なので、タイミングは定義しません。

I/Oサーバを作成したら、デバイスから読み取る項目を指定できます。 低レベルAPIの場合は、要求を自分で生成して処理する必要がありますが、Modbus I/Oでは、多数の形式とデータタイプから選択できます。 たとえば、項目400001に変数をマッピングすることでアドレス0の保持レジスタを読み取り、400001.1を選択することでこのレジスタの最初のビットを読み取り、F400001を選択することでレジスタ0と1に格納されている単精度浮動小数を読み取ることができます。

アクセスする変数を選択したら、ブロックダイアグラム上のシェア変数ノードを使用してこれらの変数を読み書きできます。 変数名をエイリアスすることもできます。

図7. シンプルなI/Oサーバアプリケーション

詳しい内容と手順については、「Connect LabVIEW to Any PLC With Modbus」を参照してください。

異なるプロトコルで多くのスレーブと通信する複雑なアプリケーションでは、標準的なModbus I/Oでは不十分な場合があります。 一般的な解決策は、OPCサーバを使用して全システムのデータを集約してから、LabVIEW DSCモジュールに含まれているOPC I/Oサーバを使用してそのOPCサーバと通信することです。

図8は、NI OPCサーバがModbusを使用してセンサと直接通信し、OPC UAがNI CompactRIO PACと通信するこのアーキテクチャの例を示しています。 NI OPCサーバにデータが集約された後、OPC I/Oサーバはデータを取り込み、LabVIEWアプリケーションと共有することができます。

図8. Modbus、NI OPCサーバ、OPC I/Oサーバを使用したSCADAアプリケーション

OPC I/Oサーバの代わりにLabVIEW DSCに含まれているOPC UAドライバを使用する類似のアーキテクチャを開発することもできます。 しかし、OPC UAドライバは下位レベルドライバであり、OPC I/Oサーバのように使いやすくはありません。

このようなアプリケーションを開発するには、まず、NI OPCサーバがスレーブデバイスと通信するための有効な構成を生成する必要があります。 これは、ドライバ構成を定義するチャンネル群と、そのドライバの個々のエンドポイントを定義するデバイス群を生成することで実現します。 デバイスを構成したら、次にタグを生成できます。

図9. 上のアーキテクチャ用のNI OPCサーバのサンプル構成

NI OPCサーバを構成した後、OPC I/Oをこれらのタグと通信するように構成できます。 Modbus I/Oサーバは、レジスタにアクセスするように構成しますが、OPC I/OサーバはOPCサーバ内のタグにアクセスするように構成します。

図10. OPC I/Oサーバを構成する

このバインドプロセスにより生成される変数をアプリケーションの中で使用することができます。

図11. OPC I/Oサーバを使用したシンプルなアプリケーション

このプロセスの実行手順は、「Connect LabVIEW to Any PLC Using OPC」を参照してください。

アプリケーションのニーズに応える

Modbusは、強力なアプリケーションを実装するためにさまざまな方法で使用できるシンプルなプロトコルです。

Modbus通信に関して、NIはアプリケーションのニーズに応えるために幅広い機能を提供する3つの主なオプションを提供しています。 1つ目の低レベルAPIは、使いやすくはないものの、プロトコルを細部まで高性能に制御することができます。 低レベルAPIを使用する場合は、すべてを手作業で行う必要があります。 シンプルな監視アプリケーションには、Modbus I/Oサーバが、Modbusデータにアクセスして提供するためのシンプルで使いやすいAPIを提供しています。 使いやすさと引き換えに、I/Oサーバでは、プロトコルに関して一部のアプリケーションで必要な場合のある細かい制御はできません。 最後に、大規模で複雑なシステムでは、データ集約用にフル装備のOPCサーバを検討することが効果的な場合があります。 その後、LabVIEW OPC UAドライバまたはOPC I/Oサーバのようなツールを使用することで、アプリケーションからこのデータにアクセスすることを可能にします。