MQTTとは何ですか？また、産業用自動化企業はMQTTをどのように使用できますか？

産業用モノのインターネット（IIoT）にまったく関わっていれば、あちこちで使用されている新しい頭字語MQTTを目にするはずです。 MQTTは自動化にかなり新しいものですが、20年以上前から存在しています。もともとは遠隔地の油田からデータを取得するためのプロトコルとして開発されましたが、最近まで、このニッチなアプリケーション以外ではあまり採用されていませんでした。現在、製造業向けのデジタルトランスフォーメーションプロジェクトの主要なプロトコルの1つとして浮上しています。

MQTTとは何ですか？

MQTTは、Message QueuingTelemetryTransportの略です。これは、クライアントサーバーのパブリッシュ/サブスクライブメッセージングトランスポートプロトコルであり、限られた帯域幅のアプリケーションで情報の小さなパケットを送信するための軽量のメッセージングプロトコルと見なされます。中核となるのは、IoT接続の中心となるOASIS標準と見なされていることです。

履歴

1990年代後半には、接続速度が非常に低く、おそらく300ボー程度の低速で、遠隔地の石油サイトからデータを送信できる軽量の通信プロトコルが必要でした。戦略は、TCPプロトコルを使用したトランスポート層ですでに提供されている機能を利用することでした。提案されたアプリケーションプロトコルは、送信ペイロードに追加された冗長性をすべて削除します。また、ステートフルである必要があり、例外によってのみ報告する必要がありました。これらの制約を念頭に置いて、Phillips66はCirrusLinkSolutionsのArlenNipperおよびIBMのAndyStanford-Clarkと協力して、現在MQTTプロトコルとして知られているものを開発しました。

初期の商用利用

自動化企業は2000年代初頭にMQTTプロトコルでアプローチされましたが、他の唯一の商用利用はFacebookMes​​sengerとAppleMessagesアプリケーションでした。関心のあった主な機能は、プロトコルがデータの状態と品質を保証することです。送信者が入力しているとき、受信者は画面上に今ではあまりにもなじみのある3つのドットを見るでしょう。一部の家庭用監視および気象データアプリケーションでも使用されていましたが、その時点では、MQTTの使用はかなり制限されていました。

自動採用

2010年代半ば、ArlenNipperは再び自動化企業にMQTTの使用を促進するよう働きかけました。大きなネットワーク需要なしに、追加の製造データを集約する必要が生じました。ただし、製造で受け入れられるようにするために開発する必要のある追加機能がいくつかありました。 Cirrus Link Solutionsは、Inductive Automationとともに、自動化に必要な属性、つまり定義されたトピックのセット、標準ペイロード、メッセージ圧縮を含む、現在のSparkplug標準の開発を進めました。

構造の概要

MQTTは、コンピューターのフォルダー構造に似た構造を使用します。例としてWindowsデスクトップを使用します。デスクトップには、マイドキュメントというフォルダがあります。 My Documentsには、Familyという別のフォルダーがあり、そのフォルダーには、各ファミリーメンバーのフォルダーがあります。私のフォルダへのパスは、Desktop / My Documents / Family/Davidになります。すべてのドキュメントをDavidに保存（公開）します。私のドキュメントを読みたい人は誰でもDavidを開く（購読する）でしょう。

MQTTプロトコルを使用するデバイスは、名前空間と呼ばれる同様のトピックパスをパブリッシュおよびサブスクライブします。コンピューターと同じように、最も一般的なものから最も具体的なものまで編成されています。サブスクライブするレベルが高いほど、より多くのデータを受信します。トピックパスの定義に役立つワイルドカードもあります。アスタリスク（*）には、現在のレベル以下のすべてが含まれます。プラス（+）は、パスを1レベル下に移動します。記事のさらに下にいくつかの例を含めました。

ISA標準との整合性

ISA-95規格は、製造業でよく理解されています。エンタープライズシステムと制御システム間のインターフェイスの標準モデルと用語について説明します。これは一般に、上部のERPと下部のデバイスから始まる階層として実現されますが、標準は主に製造データとその構造化方法を扱います。 MQTTはトピック名前空間を使用するため、これらはISA-95階層に簡単に合わせることができます。トピック名前空間は、構築時にEnterprise、Site、Area、Line、およびCellに従うことをお勧めします。パブリッシャー/サブスクライバーのルートフォルダーも適切なレベルに存在する必要があります。たとえば、セルを制御するPLCは、エンタープライズ/サイト/エリア/ライン/セルのトピックでデータを公開する必要があります。プロセスヒストリアンがエリアに固有である場合、エンタープライズ/サイト/エリアレベルですべてのデータをサブスクライブする必要があります。

アーキテクチャ

MQTTの使用から生じる一般的な質問の1つは、接続が失われたときに何が起こるかです。これらの状況を緩和するために使用できるいくつかのオプションがあります。一般的な解決策は、「ストアアンドフォワード」方式を使用することです。たとえば、制御層にあるSCADAシステムは、MQTTブローカーへの接続が再開されるまでデータを収集し続けます。ブローカー接続が再開されても、保存されているすべてのデータのタイムスタンプはそのまま残ることに注意してください。

MQTTは、バックアップブローカーの使用もサポートしています。プライマリブローカーが存在する場合、この接続が失われると、接続されているノードは自動的に別のブローカーに切り替わります。関係は通常、この機能をサポートするアプリケーション（SCADAシステムなど）を介して構成されます。

別の解決策は、クラスタリングを使用することで実現されます。これは、データを失う余裕がないアプリケーションでは一般的です。一般的な設定は、複数のMQTTブローカーをクラスターに配置することです。これらのブローカーはすべてお互いを認識しており、クラスター内でメッセージを共有します。接続が失われると、データの発行者とサブスクライバーは、データを損失することなく別のブローカーにシームレスにルーティングします。

エンタープライズアプリケーションでは、すべてのプラントからのデータを使用するのが一般的です。このシナリオでは、MQTTはストアアンドフォワードシステムと同様のブリッジングの使用をサポートします。このアーキテクチャでは、1つのブローカーが、その名前空間の一部またはすべてを別のブローカーに公開またはブリッジします。言い換えれば、プラントブローカーはエンタープライズブローカーにブリッジします。公開されたトピックと名前空間構造の両方を定義できます。これにより、公開されるデータの量が制限され、受信ブローカーにコンテキストが提供されます。

すべてのデータをアスタリスク（*）でそのまま公開し、構造を定義しないのが最も簡単な方法ですが、これにより、多くの不要で混乱を招く可能性のあるデータが生成される可能性があります。データコンテキストを提供するために、公開されたトピック名前空間の先頭にトピックを追加できます。たとえば、Enterprise/SiteをプラントのArea/+ / Cell名前空間に追加すると、Enterprise / Site / Area / +/CellがEnterpriseブローカーに送信されます。その結果、すべてのラインのセルレベルデータがこのシステムから利用できるようになります（+ワイルドカードの使用に注意してください）。

これらのシナリオはすべて展開できます。 SCADAシステムは、MQTTクラスターへのストアアンドフォワードを使用できます。プライマリクラスターとバックアップクラスターが存在する可能性がありますが、これにより不必要な複雑さが追加される可能性があります。最後に、プラントクラスターはエンタープライズクラスターにブリッジして、データの整合性を最大化できます。これは、大量の高品質データを必要とするため、エンタープライズ分析や機械学習に最適です。

セキュリティ

インターネットを介した製造データの送受信に関する主な懸念事項の1つは、サイバーセキュリティです。真に安全であるための唯一の方法はエアギャップを使用することですが、これは組織がデジタル変換する能力を妨げます。 MQTTの主な利点の1つは、セキュリティです。他の通信プロトコルではネットワークポートを開く必要がありますが、MQTTではブローカーへのアウトバウンド接続のみが必要です。プラントはインバウンドポートを開く必要がないため、IT組織にとって非常に魅力的です。

将来の考慮事項

今後の記事では、MQTTを使用した一般的なアプリケーションについて説明します。プロトコルはかなりプラグアンドプレイであることが意図されていますが、追加の技術的な詳細に関心がある可能性があります。ビジネスリーダーは、MQTTが現在のデジタルトランスフォーメーションの取り組みにどのように影響するかを検討することをお勧めします。そしてもちろん、エンジニアリングリーダーは、MQTTが彼らにどのような影響を与えるかを確実に知りたいと思うでしょう。

最後に、MQTTは既存のアーキテクチャの代替と見なされるべきではありません。インダストリー4.0の要件に合わせて、すでに実施されているものを活用します。 OPC UAおよびその他のプロトコルは、制御アプリケーションにとってより冗長であるため、引き続き必要になります。ただし、大量のデータを集約する場合、MQTTは優れた選択肢になります。