Pub-Subブリッジ

はじめに

より優れた相互運用性とシームレスな通信は、OPC UAの出現の背後にある主な動機です。クライアントサーバーモデルは、OPC UAアプリケーションの相互通信のための歴史的な方法ですが、ポイント・ツー・ポイント通信にはより適していると考えられています。

クライアントとサーバーは互いに直接接続されており、PLCやホストワークステーションが情報を要求すると、センサーやバルブなどのフィールドデバイスが情報を取得します。しかし、両端のデバイスの数が増えると、データ要求数が増え、ネットワークのスループットが低下します。さらに、クライアントサーバーモデルでは、データの応答速度が常に、両コンポーネントが対応できる最小値となっていました。

IIoTデバイスの急速な普及に伴い、クライアントサーバー機能に依存せず接続数の少ない環境で動作する、より強固な通信ネットワークが求められていました。このような緊急のニーズに応えるために、OPC UA Part 14仕様が登場しました。この仕様では、最新のIIoTのシナリオで通信を可能にする完璧なソリューションであるPub-Subモデルが取り上げられています。OPC UA Pub-Subは、あらゆるクラウドベンダーのIIoTプラットフォームに対して確立された規格です。

OPC UA Pub-Sub Bridgeは、クライアントサーバー通信とは異なり、クライアントやサーバーの制限に依存しない拡張性のある高速通信を可能にします。 このモデルでは、パブリッシャーはサブスクライバーを知ることなくメッセージをメッセージ指向ミドルウェアに送信します。同様に、サブスクライバーはパブリッシャーを知ることなく特定のメッセージに興味を示します。これらのパブリッシャーはOPC UAサーバーであり、サブスクライバーはOPC UAクライアントです。

産業界にOPC UA Pub-Subが必要である理由

OPC UAクライアントサーバーベースの通信では、サーバーはクライアントからの通信要求を待ちます。サーバーがリクエストに答えると、次の通信リクエストが来るまで、再び待機状態になります。そのため、OPC UAサーバーは、OPC UAクライアントが要求するものよりも早くデータを公開することはできません。

一般的なクライアントサーバー通信では、サービス指向アーキテクチャが採用されていますが、これは互換性や相互運用性をもたらす一方で、以下のような制限があります。

• 拡張性の制限：クライアントとサーバーが直接接続されているため、負荷が高くなると両端の能力が制限されてしまいます。OPC UAサーバーは、秒単位やミリ秒単位の更新レートを維持したまま、多くのOPCクライアントをサポートするように拡張させることはできません。
• パブリッシュサイクルへの依存：特定のパブリッシュサイクルに間に合わなかったデータサンプルは、次のパブリッシュサイクルでのみピックアップされます。
• より大きなフットプリントに対する要求：クライアントの数が増えると、複数のクライアントメッセージングセッション、データストレージ、別個のクライアントとのメッセージング要件に対応するために、サーバーのメモリと処理要件が増加します。

OPC UA Pub-Sub Bridgeアーキテクチャ

OPC UA Pub-Subは上記の課題をより安全かつ合理的な方法で対応します。ここでは、OPCアプリケーションがパブリッシャーとサブスクライバーの役割を担い、ミドルウェアを介してメッセージを交換します。メッセージ指向ミドルウェアは、プロトコルを使用して、分散アプリケーション間の接続、メッセージの送信と受信をサポートします。 Pub-Subの概念では、MQTT（Message Queue Telemetry Transport）やAMQP（Advanced Message Queuing Protocol）などのミドルウェアを使って、インターネットやクラウド上でOPC UAを直接利用することが可能です。そのため、どのアプリケーションも相互に直接通信することはありません。ミドルウェアは、メッセージの移動先を指定するブローカーの役割を果たします。

各DataSetは、DataSetWriterにより指定された特定のフォーマットのDataSetMessageとして送信されます。DataSetの書き込み形式にはJSONとUADPという2種類の形式があります。

OPC UA Pub-Subは、クライアント/サーバーが直面する課題を以下のように解決します。

• 拡張が容易： クライアントとサーバーは相互に直接接続されておらず、ブローカーミドルウェアを介して通信を行うため、どちらのデバイスの数を増やしてもパフォーマンスに影響はありません。これによりアーキテクチャの拡張性が高まります。
• データ応答速度が無制限： クライアント/サーバーモデルとは対照的に、双方の当事者がメッセージングの間隔に合意する必要はありません。サーバーは、クライアントのデータ要求に関係なく、好きなときにデータセットを発行できます。
• IIoTイネーブラー：OPC UA Pub-Subは、あらゆるクラウドベンダーのIIoTプラットフォームに対して確立された規格です。分散型インテリジェンスを実現する機能を持つPub-Subは、ネットワーク負荷とピアへの分散メッセージのバランスをIIoTの基盤となる効果的な方法で調整します。

OPC UA Pub-Sub BridgeのためにUtthungaを選ぶ理由

Utthungaは、OPC Pub-Sub製品をいち早く採用した企業の一つです。現在は、OPC UA仕様に準拠するように構築されたOPC Pub-Sub Bridgeを考案しています。OPC UA Pub-Sub Bridgeの実装において、Utthungaが最初の選択肢となる理由は以下の通りです。

1. 複数の展開シナリオ：UtthungaはOPCに関して最高のスキルを備えているため、Pub-Sub Bridgeをさまざまなバリエーションで展開していますが、ここではそれらのケースのうちの2つをご紹介します。

• 1対1：1人のパブリッシャーが1台のミドルウェアにメッセージを送り、それを介して1人のサブスクライバーが対象メッセージを受け取ります。
• 多対多： 複数のパブリッシャーが多数のミドルウェアにデータを送信し、その後、多数のサブスクライバーがメッセージを受信します。

2. 従来のフレームワークへのサポート：UtthungaのPub-Subアーキテクチャは、従来のサーバー、データベース、その他のメッセージキューなどといったOPC UA以外のデータソースに対応しています。

3. ほぼリアルタイムの応答性：Utthungaは、ほぼリアルタイム（マイクロ秒）でのメッセージの送受信や、大容量のメッセージの受信の体験をお客様に与えます。

4. エンド・ツー・エンドのセキュリティ： UtthungaのPub-Subモデルを導入すれば、どのトランスポートプロトコルが実装されていても、エンド・ツー・エンドのセキュリティをネットワークに装備できます。JSONとUADPがあれば、オンプレミスでもクラウドでも、ネットワークが安全に保たれます。

OPC UA Pub-Sub Bridgeは、産業オートメーションの未来を担うものです。OPC UA Pub-Subは、生産現場に導入されている埋め込みデバイスへの展開や、拡張可能なクラウドベースのアプリケーションへの統合を実現することで、生産現場をよりスマートにし、最適化することができます。開発の初期段階ではあるが,工業的応用範囲は広い。

オートメーション能力を次の軌道に乗せるために、ぜひ当社と提携を！