今から学ぶOPC UA⑤ ―OPC UAの通信方式―

本コラムでは、OPC UAの概要から具体的な活用方法までを複数回にわたり解説していきます。

この連載の記事一覧

第5回目の今回は、「OPC UAの通信方式」です。

はじめに

OPC UAにおけるデータ通信には、サーバー／クライアント方式とPubSub方式によるデータ通信があります。

今回は、それぞれの通信方式の特長を解説します。

サーバー／クライアント方式

サーバー／クライアント方式は、OPC UA仕様策定時からある通信方式です。データやメソッドを提供する側がOPC UAサーバー、データ操作やメソッド使用を要求する側がOPC UAクライアントとなり、サーバー、クライアント間でセッションを確立します。各種処理は要求と応答が対になっています。

OPC UA仕様におけるサーバー／クライアント方式

OPC UAクライアントでは、OPC UAサーバーのアドレススペースに設定されているノードに対する処理を要求し、OPC UAサーバーはその結果を応答します。
OPC UAサーバーが同時に確立できるセッション数は、OPC UAサーバープロファイルに依存します。なお、OPC UAの仕様書に指定されているのは最小セッション数です。このため、実際にフィールドで稼働するOPC UAサーバーでは、より多くの同時セッションを確立できるようにしていることが多いです。

サーバー／クライアント方式を利用することの利点は、アプリケーションインスタンス証明書やユーザアカウントの確認、セッションを確立したクライアントに対するRoleの付与など、OPC UAサーバーの接続相手のチェックや、データアクセス範囲を比較的容易に設定できることです。もちろんPubSub方式もOPC UAの仕様としてセキュリティが規定されていますが、少し煩雑になってしまいます。

PubSub方式

PubSub方式は、OPC UA仕様1.04から導入された通信方式です。OPC UA PubSubは、パブリッシャーが送信したデータを、サブスクライバーが取得する構成です。

OPC UA仕様におけるPubSub方式 MOM：Message-oriented Middleware（メッセージ保持システム）

OPC UAパブリッシャーは、アドレススペースにあるノード（例：バリアブルノード）の変更やイベントをパブリッシュします。サーバー／クライアント方式では、データの受け取り側（OPC UAクライアント）は内部にアドレススペースを持ちませんが、PubSub方式では受け取り側（サブスクライバー）の内部にアドレススペースを展開します。

PubSub方式の利点は、すべてのサブスクライバーがパブリッシャーの同一データストリームを使用できることです。
サーバー／クライアント方式では、OPC UAクライアントがバリアブルノードの読み出しを要求した場合、サーバーはその時点のバリアブルノードの値を返します。２つのクライアントが同一バリアブルノードの読み出しを同時に要求した場合、OPC UAサーバーはそれぞれ個別に処理します。そのため、要求のタイミングによっては、２つのクライアントは異なる値を取得することになります。一方、PubSub方式の場合は、パブリッシャーが送信したメッセージを各サブスクライバーが受け取るため、要求タイミングにかかわらず同一内容のメッセージを受け取ることができます。
また、サーバー／クライアント方式では、OPC UAサーバーは接続しているクライアント数に比例してCPU、RAMの消費が大きくなりますが、PubSub方式の場合はそのような心配がありません。

まとめ

OPC UAは、これまでのサーバー／クライアント方式に加えPubSub方式の仕様を公開することで、より柔軟なOPC UA対応システムの構築をサポートしています。ぞれぞれの通信方式の利点・欠点を把握して、より良いシステムを構築してください。

Matrikon社製品のOPC UA PubSub対応

Matrikon社は、規格に準拠した高性能なOPC UAソフトウェアを提供しています。
今回ご紹介したOPC UA PubSubは下記製品で対応しています。

Matrikon® FLEX™ OPC UA SDK
- OPC UAサーバー/クライアント双方に対応可能
- OPC UA PubSub パブリッシャー、サブスクライバー双方に対応可能
Matrikon® Data Broker (MQTTパブリッシャー機能)
- 既存OPC UAサーバーのデータをMQTT Broker、Azure、AWS等へ送信するOPC UA PubSubパブリッシャー機能