OPC UA over MQTT：ITとOT融合の未来
Neuron Team
目次
情報技術(IT)と運用技術(OT)の融合は、一般に個別に運用されていた企業ネットワークやコンピュータシステムを産業制御システムやデバイスと統合し、統一された相互接続のあるエコシステムを作り出すプロセスです。ITとOTの融合に最適なプロトコルを選択するには、特定の業種、既存のインフラ、セキュリティの考慮事項、拡大要件など様々な要因を考慮する必要があります。
OPC UAとMQTTは、このシナリオで一般的に使用されるプロトコルです。これら二つの技術が進化し続ける中、双方の利点を組み合わせた新しいプロトコルが生まれました。それがOPC UA over MQTTです。この記事では、OPC UA over MQTTについて掘り下げて、ITとOTの融合を強化するその可能性を探求します。
OPC UA over MQTTはどのようにして生まれたのか？
OPC UA はITとOTの環境を橋渡しするのによく使用されるプロトコルです。これは標準化されたデータモデルによる安全で信頼性のある通信を提供し、リアルタイムのデータ交換や複雑な情報共有に適しています。OPC UAは、内蔵されたセキュリティ機能を持ち、様々なプラットフォームやデバイスをサポートしています。
MQTT は、リソースが制限された環境での効率的なデータ送信を目的とした軽量なパブリッシュ・サブスクライブメッセージングプロトコルです。帯域幅や電力に関する考慮事項が重要なIoTやOT統合シナリオに適しています。MQTTのパブリッシュ・サブスクライブモデルにより、複数のサブスクライバーへの効率的なデータ分散が可能になります。
OPC UA over MQTT はMQTTとOPC UAを組み合わせたプロトコルであり、両方のプロトコルの利点を活かしています。OPC UAとMQTTはそれぞれ、ITとOT融合シナリオで使用される利点があります。MQTTは、OPC UAの豊富なデータコンテキストを運ぶためのトランスポートとして使用されます。このアプローチは、MQTTの軽量なパブリッシュ・サブスクライブメッセージモデルと、OPC UAの標準化されたデータモデリング、セキュリティ機能、複雑な情報交換のための広範な機能から利益を得ることができます。
MQTT Publish-Subscribeパターンから得られる利益
柔軟でスケーラブルなITとOTインフラストラクチャ
MQTT（Message Queuing Telemetry Transport）は、主にメッセージ駆動型プロトコルです。それはパブリッシュ・サブスクライブメッセージングパターンに従っており、パブリッシャーはメッセージを中央のメッセージブローカーに送信し、サブスクライバーはブローカーからそれらのメッセージを受信します。MQTTブローカーはパブリッシャーとサブスクライバー間の中間者として機能します。パブリッシャーにより発行されたメッセージを受け取り、特定のトピックについてメッセージを受信することに関心を表明したサブスクライバーにそれらを転送します。
パブ・サブメッセージングシステムは、クライアント・サーバーシステムより本質的にスケーラブルです。クライアント・サーバーモデルでは、各クライアントはサーバーとの接続を確立して維持する必要がありますが、これはクライアント数が増加するとパフォーマンスのボトルネックになり得ます。パブ・サブモデルでは、パブリッシャーはメッセージを集中化されたブローカーに送信し、ブローカーは関心のあるサブスクライバーにメッセージを伝達します。このアーキテクチャは、パブリッシャーとサブスクライバーの数が増えるにつれて、より効果的にスケールします。
ネットワーク帯域幅の利用
クライアント・サーバーシステムでは、各クライアントのリクエストがポーリングメカニズムを使用することによりネットワークとサーバー上でトラフィックを生成します。この結果、ターゲット値に更新がなくても不必要に多くのネットワークトラフィックを生じてしまいます。パブ・サブでは、新しいデータが利用可能になったときにのみ、サブスクライバーは更新を受け取ります。これにより不要なネットワーク負荷が軽減されます。これは、IoTのようなアプリケーションで重要です。ここでは、センサーデータやステータスの更新が直ちに届けられる必要があります。
イベント駆動型アーキテクチャ
パブ・サブは、コンポーネントがデータのイベントや変化に反応するイベント駆動型アーキテクチャにうまく沿います。特定の条件やイベントに基づいてアクションをトリガーする必要があるシナリオに特に有用です。これは、送信者（パブリッシャー）と受信者（サブスクライバー）の切り離しに利益を与えます。パブリッシャーは自分のサブスクライバーが誰であるか知る必要がなく、サブスクライバーも自分のパブリッシャーが誰であるか知る必要はありません。この分離は、互いに影響を与えることなくコンポーネントを柔軟に実行することを可能にし、効率的なリソース利用と応答性に繋がります。
したがって、パブリッシャーとサブスクライバーは互いの存在や具体的な実装詳細を知る必要がありません。これにより、システム全体を混乱させずに個々のコンポーネントをより簡単に置き換えたりアップグレードしたりすることが可能になります。
OPC UAによる豊かなデータコンテキスト
MQTT Pub-Subメカニズムによる利点に加えて、OPC UAは多様なデバイスやアプリケーション間のシームレスな通信を確保するための別の重要なレベルを提供します。OPC UAは異なるシステム、ベンダー、および業界間の相互運用性と標準化に強い焦点を当てて設計されています。複雑なデータ構造、階層的なデータモデル、メタデータ、堅固なセキュリティ機能の取り扱いが得意であり、複雑なデータ関係を持つアプリケーションに適しています。これにより、様々な工業ドメインにおける基盤技術やベンダーに関わらず、複雑な工業環境においてプロトコルが適合します。
OPC UAは、製造業、プロセスオートメーション、エネルギー、自動車産業などの業界で広く使用されています。これらのセクターは、運用にロバストで標準化された通信を依存しています。発電所、化学処理、航空宇宙などのアプリケーションシナリオは非常に重要で、信頼性と安全性が最優先事項です。
OPC UA over MQTTメッセージ構築のための運用モデル
提供される図は、メッセージの生成と発送のためにパブリッシャー内での内部ステップ、およびそのプロセスに必要なパラメータを示しています。また、サブスクライバー内でのメッセージの受信、デコード、および理解のためのプロセス、およびこれらのアクションを実行するのに必要なパラメータモデルも描かれています。
パブリッシャーの処理
ステップ1 - データ収集
最初の段階では、データ（DataSet）が収集され、公開の準備が行われます。このプロセスには、PublishedDataSetと呼ばれる構造体を使って収集の設定が行われます。PublishedDataSet内では、DataSetMetaDataとして知られるデータの重要な詳細が定義されています。このデータ収集プロセスの結果は、DataSet内の個々のフィールドに対する値の作成が成されます。
ステップ2 - DataSetWriterとDataSetMessageの生成
次に、DataSetWriterというコンポーネントを使用して「DataSetMessage」と呼ばれるものを生成します。WriterGroup内の異なるDataSetWriterによって生成された複数のDataSetMessageを一つの統合されたNetworkMessageにまとめることができます。
ステップ3 - NetworkMessageの生成
NetworkMessageの生成には、前のステップで取得した情報と、PubSubConnectionで指定されたPublisherIdを利用します。このNetworkMessageの構造は、使用される特定のコミュニケーションプロトコルに準じます。
ステップ4 - NetworkMessageの配信
最終的なステップでは、完全に形成されたNetworkMessageを指定されたメッセージ指向ミドルウェアに転送します。これは、この目的のために指定されたプリデファインドアドレスを活用することによって達成されます。
サブスクライバーの処理
ステップ1 - 接続と購読の開始：
サブスクライバーは、適切なメッセージ指向ミドルウェアを選び、提供されたアドレスを使用して接続を確立します。これは、OPC UA UDPのマルチキャストを使用するか、MQTTのためにブローカーに接続することで行います。サブスクライバーは、入ってくるメッセージを監視することを開始します。PublisherId、DataSetWriterId、またはDataSetClassIdなどのフィルターを設定して、指定された基準に合わないメッセージを取り除きます。
ステップ2 - 入ってくるNetworkMessagesの処理
NetworkMessageが届いたとき、それは出版者が使用するセキュリティパラメーターを用いて、解読とデコードの対象となります。
ステップ3 - デコードとアプリケーション固有の処理
関連するDataSetMessageは、対応するDataSetReaderに指示されます。DataSetMessageの内容はDataSetMetaDataを使用してデコードされ、これには包括的なフィールド構文、バージョン情報、および関連するプロパティが含まれています。アプリケーション固有の処理が続き、これには、受信した値をサブスクライバーのOPC UA AddressSpace内のノードにマッピングするなどの作業が含まれる場合があります。
ステップ4 - SubscribedDataSetの設定と管理
サブスクライバーは、データの送信のためにSubscribedDataSetを設定します。
2つの明確な選択肢が存在します：
- TargetVariablesの設定は、DataSetMessageフィールドをサブスクライバーのOPC UA AddressSpace内の既存の変数にディスパッチします。
- SubscribedDataSetMirrorの設定は、受信したDataSetフィールドをサブスクライバーのOPC UA AddressSpace内の変数に変換する際に使用されます。これらの変数が存在しない場合、それらはサブスクライバーの設定の一部として作成されます。
設定ツール
パブリッシャとサブスクライバーの両方の設定とカスタマイズは、専用の設定ツールを通じて共通に容易にされます。この設定プロセスは主に2つの方法で行うことができます：
PubSub設定情報モデルに準拠した一般的なOPC UA PubSub設定ツールを活用します。
注意：PubSub設定情報モデルに沿って、パブリッシャもサブスクライバーも自身自身をOPC UAサーバとして機能させなければなりません。
アプリケーションの特定の特徴に対応するために、ベンダー固有の設定ツールを活用します。
設定手順は、データセットの配置と、最終的な公開に向けたデータソースの決定を含みます。この設定は、PubSub設定モデルを使用して行うことができ、これは標準化されたフレームワークを概説しています。または、個々のベンダーが設計した設定ツールを使用して、特定の提供物に合わせてカスタマイズすることもできます。
OPC UAアプリケーションは、パブリッシャーとして事前に設定することができますが、メッセージに含める内容やメッセージの送信頻度を指定する追加の設定がしばしば必要です。これにより、アプリケーションのニーズに応じてメッセージの内容と送信間隔を正確に調整し、OPC UAネットワーク内のパブリッシャーとサブスクライバー間の効果的な通信を確実にします。
ITとOT組織における実証済みのプロトコル
実際に、OPC UA over MQTTは様々な業界で広く採用され、認識されている実証済みのプロトコルです。スーパーバイザリーコントロールおよびデータ取得(SCADA)システム、製造実行システム(MES)、産業用IoTソリューションなどで使用されています。Siemens、Beckhoff、KUKAなどの多くの産業自動化ベンダーは、PLCやセンサーからソフトウェアプラットフォームに至るまでの製品でOPC UA over MQTTサポートを提供しています。この広範なサポートはプロトコルの成熟度を示しています。
OPC UA over MQTTのIoTデプロイメントへの適合性はクラウドベースのアプリケーションにまで及びます。AWS、Azure、GCPなどの多くのクラウドプロバイダーがこのプロトコルのサポートを提供し、IoTデータをクラウドサービスにシームレスに統合して、ストレージ、分析、ビジュアライゼーションが可能です。OPC UA over MQTTを実行することで、OPC UAの機能をクラウドからエッジデバイスへと拡張し、産業用IoTエコシステムへのシームレスな統合を実現できます。
セキュリティと認証
OPC UA over MQTTは、認証、認可、暗号化、データの完整性を含む包括的なセキュリティメカニズムを提供し、産業環境に固有のセキュリティの課題に対処します。これにより、機密データを保護し、不正アクセスを防ぐのに役立ちます。
まとめ
OPC UA over MQTTは、OPC UAとMQTTプロトコルの強みを組み合わせることで、両方の世界の最良のものをもたらします。この統合は、効率的な通信、標準化されたデータモデリング、および相互運用性を提供し、産業およびIoTアプリケーションにとって魅力的な選択肢となります。MQTTの軽量さとパブリッシュ-サブスクライブアーキテクチャを活用しつつ、OPC UAの堅牢なデータ表現と標準化されたサービスを維持することで、OPC UA over MQTTは現代の通信ニーズに対する前向きで多様なソリューションを提供します。
EMQX MQTTブローカーとNeuronEXゲートウェイは、OPC UA over MQTTを完全に有効にします。EMQXのMQTTブローカーとしての実績は、信頼性の高いメッセージ配信と効率的なデータ配布を保証する一方、NeuronのOPC UAからMQTTへのブリッジングに特化した機能により、両方のプロトコルの強みを活用できます。