各通信タイプにはターゲット(通常はデータ収集アプリケーションシステムまたはコントローラ)とホスト(通常はHMIを表示)が含まれ、複数の構成で配置できます。単一のターゲットと単一のホスト(1:1)間、複数のターゲットと単一のホスト間(N:1)、または単一のターゲットと複数のホスト間(1:N)で通信を行うことができます。以下のセクションでは、機械制御アプリケーションで使用される各通信タイプ、それらの一般的なシステム構成、ネットワーク接続およびデータ転送要件について説明します。
コマンドまたはメッセージベース通信は、特定のイベントがトリガとなる不定期の情報転送です。イベントとはボタンの押下やアラームであり、それらが特定の応答のトリガとなります。コマンドベースアーキテクチャでは、2つのシステムタイプ、コマンダシステム(ホスト)とワーカシステム(ターゲット)が使用されます。コマンダは、ワーカが実行する命令を送信します。コマンドは損失を発生させない方法で、遅延を最小限に抑えて送信する必要があります。たとえば、ボタンを押したオペレータは、もう一度ボタンを押さなくても関連付けられた動作が実行されることを期待します。また、システムが妥当な時間内に応答することも期待します。最も一般的な構成は1:1ですが、N:1と1:Nも可能です。
プロセスデータ通信とは、プロセス変数の最新値を定期的に転送することです。このタイプの通信は最も一般的な通信であり、制御アプリケーションや現在のシステム状態の表示に使用されるHMIに有益です。 たとえば、1つ以上の組込コントローラから、機械のステータスを監視するHMIに送信される定期的な更新に使用されます。 オペレータは機械の現在の状態を知る必要があります。つまり、リアルタイムコントローラまたはHMIは最新値に対してのみ動作するので、ロスレス伝送は要件にはなりません。
このタイプのデータ転送は、組込コントローラ間で使用されることがあり、高速実行が必要となる場合があります。 ただし、プロセスデータ通信の最も一般的な用途はHMIの更新です。 このタイプの通信では、データを表示するのは人なので、アップデートレートは低速です。通常は1~30 Hzのアップデートレートで十分です。これより高速の場合、CPUやメモリリソースに負荷がかかるだけでなく、人間のオペレータの視覚的な処理能力を超えた情報が伝送されます。おおよその目安としては、数値表示のアップデートレートは1〜2 Hz、グラフィカル表示の場合は、30 Hzでスムーズに更新されます。
データをストリーミングする場合、連続的に大量の情報が送信されますが、必ずしもリアルタイムではありません。このタイプの通信は、大量のデータを送信し、各データポイントをキャプチャする必要がある場合に有益です。常にではありませんが、多くの場合ストリーミングは単方向で、1:1構成です。データを連続的にバッファリングするので、データの損失はありません。ストリーミング通信は通常、ターゲットが高速データ収集を行っていて、そのデータをロギングや後処理のために転送する必要がある場合に使用されます。
通信タイプ |
一般的な構成 |
特徴 |
要件 |
メッセージベース |
1:N |
イベント駆動型、コマンド |
低遅延、確実な配信を保証 |
プロセスデータ |
N:1 |
シングルポイント、最新値 |
最新値、確実な配信の保証は不要 |
ストリーミングバッファ型 |
1:1 |
連続データ転送 |
高スループット、確実な配信を保証 |
表1.1.機械制御通信タイプのまとめ
アプリケーション用のネットワークプロトコルを選択する際、以下を含む多数の要因を評価する必要があります。
上で説明した通信タイプとシステム構成は、アプリケーション用ネットワークプロトコルを選択する際の最大の決定要因となります。性能と使いやすさの要件は、使用するアプリケーションやプログラミング経験によって異なります。最後に、CやVBで開発されたアプリケーションなど、他社製アプリケーションと通信するアプリケーションを開発する予定の場合は、他社製APIとインタフェースできるネットワークプロトコルを使用する必要があります。これらの要因を検討することで、適切なアプリケーションを選択できます。各ネットワークプロトコルについて、上記要因をまとめた表1.2を参照してください。
API | タイプ | 性能 | 使いやすさ | サポートされている構成 | 他社製APIの可否 |
シェア変数 | LabVIEWの機能 | 1:1、N:1、1:N | Measurement StudioおよびCVI | ||
ネットワークストリーム | LabVIEWの機能 | 1:1 | 現時点では不可 | ||
TCP/UDP | インターネットプロトコル | 1:1、N:1、1:N | 可 | ||
Webサービス | インターネットプロトコル | *
| 1:1、N:1、1:N | 可 |
表1.2.ネットワークプロトコルのまとめ( = 優、 = 良、 = 可、* = Webサービスで実行されるアクションにより異なる)
TCPおよびUDPインターネットプロトコルは、本稿で説明するすべてのネットワークプロトコルが使用する下位レベルのビルディングブロックです。他のすべてのプロトコルは、これらのプロトコルの上で使いやすい抽象化を行います。そのため、TCPとUDPは最大の性能を発揮し、下位レベルの制御と最大の柔軟性を提供します。TCPとUDPは、STMのような独自のカスタムプロトコルの構築に使用できます。
TCPは信頼性の高いポイントツーポイント通信プロトコルです。データは順番に損失のない方法で配信されます。接続ベースのプロトコルなので、データ転送の前にクライアントとサーバの接続を確立する必要があります。データを確実に配信するために、TCPは肯定応答を受信するまでデータを再送信します。TCPクライアントとサーバは、指定されたポートを介して通信します。
UDPはデータを指定されたポートにパブリッシュしますが、データを送信する前にクライアントとの接続を必要としない点がTCPと異なります。送信先にデータを受信する接続がない場合、データはそのまま破棄されます。配信が成功したかどうかはチェックされません。このため、UDPはロスレスデータ転送が必須のアプリケーションでは使用できません。
UDP機能は、単一のクライアントとの通信に使用できるほか、データを複数のクライアントにブロードキャストできます。UDPマルチキャストは、ネットワーク上の単一の送信側と複数のクライアントの間で、送信側がクライアントのリストを維持することなく効率的に通信するために使用されるモードです。UDPの転送レートは、ここで説明したすべてのプロトコルの中で最高ですが、ロスレスデータ伝送は保証されません。
TCPとUDPは高スループットネットワークプロトコルですが、実装は容易ではありません。ネットワーク接続は手動で管理する必要があり、接続ごとに1つのポートを使用します。TCPとUDPでは、すべてのデータを文字列形式で送信する必要があります。つまり、送信者はすべてのデータを文字列に平坦化し、受信者はデータを文字列から非平坦化する必要があります。そのため、文字列以外のデータ伝送に複雑さが加わります。
TCPとUDPはメッセージベースの通信およびカスタムストリーミングアプリケーションに優れたツールです。これらは、あらゆるタイプの構成をサポートします。また、業界規格であるため、他社製アプリケーションで使用できます。
ネットワーク共有シェア変数は、データを共有するための使いやすいLabVIEWツールです。これらは容易に実装でき、ほとんどのLabVIEWデータタイプとカスタムタイプ定義をサポートします。
LabVIEWのネットワーク変数は、ネットワーク変数ノード、シェア変数エンジン、NI Publish-Subscribe Protocol(NI-PSP)という3つの部分で構成されています。ネットワーク変数ノードはブロックダイアグラム上に配置され、変数の読み取りおよび書き込み操作を実行します。シェア変数エンジンは、ネットワーク共有されたデータをホストするソフトウェアコンポーネントです。リアルタイムターゲットやWindows PCでホストすることができますが、少なくとも1台のネットワークコンピュータで動作している必要があります。 NI-PSPは、ネットワークシェア変数の転送を最適化する独自のネットワークプロトコルです。このプロトコルはTCP/IPをベースとし、効率的かつ信頼できる方法でネットワークを介してデータを伝送できるようにします。
ネットワーク共有シェア変数でバッファを有効にできます。これは、疑似ロスレスN:1および1:N通信を簡単に実装する方法を必要としている場合に適しています。シェア変数バッファは、一時的なネットワークの遅延によるデータ損失の防止に役立ちますが、ロスレスデータ転送を保証するわけではありません。あるクライアントのデータ書き込み速度が、もう一方のクライアントの読み取り速度より速い場合、結果的にオーバーフローが発生し、データは失われます。データフローは、オーバーフローを防ぐように管理されていません。すべてのクライアントが十分な高速レートで読み取りを行っても、データの伝送中にネットワーク障害によって基本となるTCP接続が中断すると、データは失われる可能性があります。損失のない、ポイントツーポイントのデータ転送が必要な場合は、ネットワークストリームが推奨されます。ネットワーク共有シェア変数は、プロセス変数の最新値が重要なプロセスデータ通信に最も適しています。
ネットワークストリームは、効率的なデータストリーミングを行うことを目的としてLabVIEW 2010でリリースされたLabVIEW機能です。 使いやすい上位レベルの抽象化によって、接続、接続解除およびデータフロー制御を処理できると同時に、未処理のTCP/UDPと同様のスループットを維持できます。ネットワークストリームは、書き込み/読み取りエンドポイントで構成されるロスレスで単方向の1対1通信チャンネルです。ロスレスという性質上、メッセージベース通信の基礎としても使用できます。
ネットワークストリームは、クラスタや配列を含むほとんどのLabVIEWデータタイプをネットワーク経由で転送できますが、ストリームは以下のデータタイプで最も効率的です。
ネットワークストリームはコンピュータからコンピュータへ、コンピュータからリアルタイムターゲットへ、またはリアルタイムターゲットからリアルタイムターゲットへデータを受け渡すことができます。ネットワークストリームは単方向であるため、双方向またはエンドポイント間でデータを受け渡す場合は、2つのストリームを開く必要があります。同様に、複数のターゲットにデータを渡す必要がある場合は、複数のストリームを開く必要があります。
Webサービスでは、標準的なWebブラウザを始めとするHTTP対応Webクライアントでネットワーク通信するWebアプリケーションを作成できます。LabVIEWでは、VIをサーバ側のWebサービスとしてパブリッシュできます。このVIはWebメソッドVIと呼ばれます。このWebサービスは、実行可能ファイル自体のWebサーバまたはアプリケーションWebサーバにデプロイされ、Windows PCやNI Real-Timeコンピューティングプラットフォーム上でホストすることができます。このLabVIEW機能には、NI製品に限らず、多くのHTTP対応デバイスおよびアプリケーションとインタフェースできるという利点があります。多くのユーザが、多数の異なるプラットフォームおよび場所から1つ以上のアプリケーションを監視できます。使いやすさと効率は、WebクライアントとWebアプリケーションのプログラミングに関する知識によって異なります。
データはURLと標準のHTTPメソッドを使用するWebメソッドVIで交換されます。たとえば、POSTなどの標準的なHTTPメソッドを使用して、制御器用の入力データをWebクライアントからWebメソッドVIに入れて提供できます。データは、VIの出力端子から、またはWebサーバを介したデータのストリーミングによってHTTPクライアントに返されます。 端子メソッドでは、Webサーバは要求を受け取ると、出力端子に配線されたデータをExtensible Markup Language(XML)文字列としてWebクライアントに返します。Webサービスは、Hypertext Markup Language(HTML)、JavaScript Object Notation(JSON)、またはテキスト形式でデータを返すように構成することもできます。WebメソッドVIは、ストリーム出力モードを使用するように構成することもできます。この出力モードでは、カスタマイズされた形式でデータを返すことができ、バッファを実装し、カスタムHTMLヘッダを使用できます。これら2つの出力モードを備えているため、Webサービスは監視またはストリーミングアプリケーションに適しています。
機械制御アプリケーションの各通信タイプに最も適したネットワークプロトコルを以下にまとめます。
メッセージベース通信では、信頼性の高い伝送と高速な転送レートが求められます。表1.3に、メッセージベース通信のすべてのオプションを示します。このアプリケーションには、ネットワークストリームが最も適しています。これらは信頼性が高く、使いやすく、高速転送レートを提供します。ただし、1:NまたはN:1システム構成が必要な場合や他社製アプリケーションを使用してデータを転送する必要がある場合は、TCP/UDPの方が適しています。Nが少数の場合は、複数のネットワークストリームを使用して使いやすさを優先する方法もあります。TCPと同様の解析性能を備え、かつ使いやすいWebサービスも使用できます。
API |
タイプ |
性能 |
使いやすさ |
サポートされている構成 |
他社製APIの可否 |
コメント |
ネットワークストリーム |
LabVIEWの機能 |
1:1 |
現時点では不可 |
推奨プロトコル | ||
TCP/UDP |
プリミティブ |
1:1、N:1、1:N |
可 |
N:1または1:N構成または他社製アプリケーションと通信する場合
| ||
Webサービス |
LabVIEWの機能 |
1:1、N:1、1:N |
可 |
表1.3 メッセージベース通信に適したネットワークプロトコル
プロセスデータ通信では最新値のみが焦点となります。したがって、配信の保証や転送速度はそれほど重要ではありません。表1.4に、プロセスデータ通信のすべてのオプションを示します。このアプリケーションに推奨されるLabVIEW機能はシェア変数です。これらは使いやすく、多数のシステム構成が可能です。また、ネットワーク接続を自動的に管理します。LabVIEWを使用せずにコンピュータ上の複数の場所からデータを監視する必要がある場合は、Webサービスを使用する必要があります。同様に、他社製アプリケーションでデータを監視する場合は、TCP/UDPを使用する必要があります。
API |
タイプ |
性能 |
使いやすさ |
サポートされている構成 |
他社製APIの可否 |
コメント |
シェア変数 |
LabVIEWの機能 |
1:1、N:1、1:N |
Measurement StudioおよびCVI |
推奨プロトコル | ||
Webサービス |
LabVIEWの機能 |
1:1、N:1、1:N |
可 |
1:N構成の場合 | ||
TCP/UDP |
プリミティブ |
1:1、N:1、1:N |
可 |
他社製アプリケーションと通信する場合 |
表1.4 プロセスデータ通信に適したネトワークプロトコル
ストリーミング通信では、高速転送レートと信頼性の高い伝送が求められます。表1.5に、ストリーム/バッファ型通信のすべてのオプションを示します。このアプリケーションにはネットワークストリームが推奨されます。N:1または1:N構成の場合と、他社製アプリケーションにデータをストリームする必要がある場合は、TCP/UDPを使用する必要があります。
API |
タイプ |
性能 |
使いやすさ |
サポートされている構成 |
他社製APIの可否 |
コメント |
ネットワークストリーム |
LabVIEWの機能 |
1:1 |
現時点では不可 |
推奨プロトコル | ||
TCP/UDP |
プリミティブ |
1:1、N:1、1:N |
可 |
N:1および1:N構成、および他社製アプリケーションと通信する場合 |
表1.5 ストリーム/バッファ型通信に適したネトワークプロトコル